2010/1/4 Erik Jones <ejo...@engineyard.com>: > 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:
That's true, but what I said is also true. It CAN be used in an index scan, and on a sufficiently large table it WILL be used in an index scan (I tried it). But the planner doesn't automatically use an index just because there is one; it tries to gauge whether that's the right strategy. Unfortunately, in cases where it is comparing to a function rather than a constant, its estimates are not always terribly accurate. One thing I notice is that the OP has not included any information on how fast the seqscan or index-scan actually is. If the seqscan is slower than the index-scan, then the OP might want to consider adjusting the page cost parameters - EXPLAIN ANALYZE output for both plans (perhaps obtained by temporarily setting enable_seqscan to false) would be helpful in understanding what is happening. ...Robert -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
