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
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 |