Trim performance on 9.5
Hi,
I recently did major improvements on perfomance on our routines by simply
removing the call for trim functions on specific bottlenecks. Please see
images attached for a simple example.
I'm using PostgreSQL version 9.5.5-1.pgdg80+1 on Debian 8.6. Someone knows
if it's a bug on trim function? Thanks in advance.
--
William Ivanski
Attachments:
Pasted image at 2016_11_18 11_54 AM.pngimage/png; name="Pasted image at 2016_11_18 11_54 AM.png"Download
Pasted image at 2016_11_18 11_54 AM (1).pngimage/png; name="Pasted image at 2016_11_18 11_54 AM (1).png"Download
On 2016-11-18 15:06, William Ivanski wrote:
Hi,
I recently did major improvements on perfomance on our routines by
simply removing the call for trim functions on specific bottlenecks.
Please see images attached for a simple example.I'm using PostgreSQL version 9.5.5-1.pgdg80+1 on Debian 8.6. Someone
knows if it's a bug on trim function? Thanks in advance.--
William Ivanski
Did you run EXPLAIN on these queries?
I'm guessing that you have an index on the field, but not on
TRIM(field),
which would mean that the database is forced to seqscan to fetch every
row value, trim it and then compare it.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
I just ran EXPLAIN ANALYZE, please see images attached. Field doesn't have
a index.
Em sex, 18 de nov de 2016 às 12:16, vinny <vinny@xs4all.nl> escreveu:
On 2016-11-18 15:06, William Ivanski wrote:
Hi,
I recently did major improvements on perfomance on our routines by
simply removing the call for trim functions on specific bottlenecks.
Please see images attached for a simple example.I'm using PostgreSQL version 9.5.5-1.pgdg80+1 on Debian 8.6. Someone
knows if it's a bug on trim function? Thanks in advance.--
William Ivanski
Did you run EXPLAIN on these queries?
I'm guessing that you have an index on the field, but not on
TRIM(field),
which would mean that the database is forced to seqscan to fetch every
row value, trim it and then compare it.
--
William Ivanski
Op 18/11/2016 om 16:58 schreef William Ivanski:
I just ran EXPLAIN ANALYZE, please see images attached. Field doesn't
have a index.Em sex, 18 de nov de 2016 às 12:16, vinny <vinny@xs4all.nl
<mailto:vinny@xs4all.nl>> escreveu:On 2016-11-18 15:06, William Ivanski wrote:
Hi,
I recently did major improvements on perfomance on our routines by
simply removing the call for trim functions on specific bottlenecks.
Please see images attached for a simple example.I'm using PostgreSQL version 9.5.5-1.pgdg80+1 on Debian 8.6. Someone
knows if it's a bug on trim function? Thanks in advance.--
William Ivanski
Did you run EXPLAIN on these queries?
I'm guessing that you have an index on the field, but not on
TRIM(field),
which would mean that the database is forced to seqscan to fetch every
row value, trim it and then compare it.--
William Ivanski
Neither exeution times are really "fast", I'd suggest creating an index
on the TRIM() version of the field.