Re: forced sequential scan when condition has current_user

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