Re: forced sequential scan when condition has current_user

From: Erik Jones <ejones(at)engineyard(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Keresztury Balázs <balazs(at)gaslightmusic(dot)hu>, pgsql-performance(at)postgresql(dot)org
Subject: Re: forced sequential scan when condition has current_user
Date: 2010-01-04 23:13:43
Message-ID: E56D1346-6E42-40D5-9CF1-239F5104F3A5@engineyard.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance


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:

"A STABLE function cannot modify the database and is guaranteed to return the same results given the same arguments for all rows within a single statement. This category allows the optimizer to optimize multiple calls of the function to a single call. In particular, it is safe to use an expression containing such a function in an index scan condition. (Since an index scan will evaluate the comparison value only once, not once at each row, it is not valid to use a VOLATILE function in an index scan condition.)"

postgres=# select provolatile from pg_proc where proname = 'current_user';
provolatile
-------------
s

So, I think the OP's question is still valid.

Erik Jones, Database Administrator
Engine Yard
Support, Scalability, Reliability
866.518.9273 x 260
Location: US/Pacific
IRC: mage2k

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Madison Kelly 2010-01-05 00:34:31 Re: DB is slow until DB is reloaded
Previous Message Scott Marlowe 2010-01-04 22:51:37 Re: DB is slow until DB is reloaded