Message-ID: <4B42A068.103@postnewspapers.com.au>
Date: Tue, 05 Jan 2010 10:14:00 +0800
From: Craig Ringer <craig@postnewspapers.com.au>
User-Agent: Thunderbird 2.0.0.23 (X11/20090817)
MIME-Version: 1.0
To: Erik Jones <ejones@engineyard.com>
CC: Robert Haas <robertmhaas@gmail.com>, =?ISO-8859-1?Q?Keresztury_Bal=E1?=
	=?ISO-8859-1?Q?zs?= <balazs@gaslightmusic.hu>,
	pgsql-performance@postgresql.org
Subject: Re: forced sequential scan when condition has current_user
References: <000f01ca8d87$88e71f30$9ab55d90$@hu>
	<603c8f071001041359u58159c49k10587c7c46424672@mail.gmail.com>
	<E56D1346-6E42-40D5-9CF1-239F5104F3A5@engineyard.com>
In-Reply-To: <E56D1346-6E42-40D5-9CF1-239F5104F3A5@engineyard.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

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