From: | gmb <gmbouwer(at)gmail(dot)com> |
---|---|
To: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: optimize pg_tables query ( text vs varchar ) ...why ? |
Date: | 2017-08-16 14:58:27 |
Message-ID: | 1502895507515-5978619.post@n3.nabble.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Thanks for taking the time, Tom.
Tom Lane-2 wrote
> After that, the planner has to implement the query, and the problem
> is that the available indexes are on "schemaname" not "schemaname::text",
> and they can only use the name = name operator anyway.
Did some digging earlier, and found exactly what you refer to here: seq scan
when using 'text' and index scan on 'name'.
I was not aware that an "incorrect" typecast can have that effect on how the
planner choose to use indexes or not use them ( may have to go back and
review a lot of other poor performing queries as well ).
Tom Lane-2 wrote
> Personally I'd have left the function parameters as text and inserted
> explicit coercions:
Just out of curiosity , is there a reason why this will be you preference ?
I ran some benchmarks using *function tableexists( s name, t name )* and
the performance turned out pretty well.
I guess, from a "readability" point of view it may be unclear to uninformed
people what a 'name' type actually is ( it was unknown to me until this
morning ), so that may be reason enough to stick with "known" types like
TEXT.
Thanks, appreciate this.
Regards
gmb
--
View this message in context: http://www.postgresql-archive.org/optimize-pg-tables-query-text-vs-varchar-why-tp5978592p5978619.html
Sent from the PostgreSQL - general mailing list archive at Nabble.com.
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2017-08-16 15:20:51 | Re: optimize pg_tables query ( text vs varchar ) ...why ? |
Previous Message | Tom Lane | 2017-08-16 14:36:14 | Re: optimize pg_tables query ( text vs varchar ) ...why ? |