Re: Question about a query plan

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Thomas O'Connell" <tfo(at)sitening(dot)com>
Cc: Bill Moseley <moseley(at)hank(dot)org>, pgsql-general(at)postgresql(dot)org
Subject: Re: Question about a query plan
Date: 2005-09-17 04:52:28
Message-ID: 4845.1126932748@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

"Thomas O'Connell" <tfo(at)sitening(dot)com> writes:
> On Sep 16, 2005, at 9:18 AM, Bill Moseley wrote:
>> First question is why the planner is not using an index scan when I
>> use "now()" or CURRENT_TIMESTAMP?

> It also used to be the case (pre-8.0; I couldn't find in the release
> notes whether this was an 8.0 or 8.1 fix) that now() and
> CURRENT_TIMESTAMP were not indexable, I think because of mutability.

8.0 fix. It's not that they're "not indexable" per se, it's that
pre-8.0 planners punted when it came to estimating what fraction of rows
would meet a condition like "timestampcol > now()" --- and the default
estimate for such things doesn't favor an indexscan. The 8.0 change is
to go ahead and run the function and see what value it's returning now
(pardon the pun) and then compare that to the column's statistical
histogram to derive a rows estimate. It's entirely likely that we'll
get ragged on eventually because of cases where this procedure generates
bad estimates ... but for the moment it seems like a win.

regards, tom lane

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2005-09-17 05:11:55 Re: Setting WHERE on a VIEW with aggregate function.
Previous Message brew 2005-09-17 01:36:01 Re: pg_ctl reload breaks our client