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.
