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. -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
