From: Craig Ringer <craig@postnewspapers.com.au>
To: Erik Jones <ejones@engineyard.com>
Cc: Robert Haas <robertmhaas@gmail.com>
Cc: Keresztury Balázs <balazs@gaslightmusic.hu>
Cc: pgsql-performance@postgresql.org
Subject: Re: forced sequential scan when condition has current_user
Date: Tue, 05 Jan 2010 10:14:00 +0800
Message-ID: <4B42A068.103@postnewspapers.com.au> (raw)
In-Reply-To: <E56D1346-6E42-40D5-9CF1-239F5104F3A5@engineyard.com>
References: <000f01ca8d87$88e71f30$9ab55d90$@hu>
<603c8f071001041359u58159c49k10587c7c46424672@mail.gmail.com>
<E56D1346-6E42-40D5-9CF1-239F5104F3A5@engineyard.com>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: craig@postnewspapers.com.au, ejones@engineyard.com, robertmhaas@gmail.com, balazs@gaslightmusic.hu
Subject: Re: forced sequential scan when condition has current_user
In-Reply-To: <4B42A068.103@postnewspapers.com.au>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox