Erik Jones wrote: > On Jan 4, 2010, at 1:59 PM, Robert Haas wrote: > >> The thing is, PostgreSQL doesn't know at planning time what the value of >> current_user() will be, so the plan can't depend on that; the planner >> just takes its best shot. > > current_user() is a stable function and the manual is explicit that the > result of stable function can be used in an index scan:
Yes ... but the planner doesn't know the value current_user will return, so it can't use its statistics on the frequency with which a _particular_ value occurs to make decisions. It has to come up with the best generic plan for any value that current_user might return. It's as if current_user were a query parameter that won't be resolved until EXECUTE time. Arguably, in this particular case the planner *could* know what value current_user will return, but adding such special cases to the planner without a really good reason seems undesirable. -- Craig Ringer -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
