Re: query planner oddity for data constant vs current_date - Mailing list pgsql-general

From Tom Lane
Subject Re: query planner oddity for data constant vs current_date
Date
Msg-id 9651.1029523266@sss.pgh.pa.us
Whole thread Raw
In response to query planner oddity for data constant vs current_date  ("Bryan White" <bryan@arcamax.com>)
List pgsql-general
"Bryan White" <bryan@arcamax.com> writes:
> I have noted that selects base on a date literal are perform differently
> than selects based on the CURRENT_DATE.  For example:
> ------
> explain select count(*) from orders where shipdate = current_date;
> Aggregate  (cost=98881.63..98881.63 rows=1 width=0)
>   ->  Seq Scan on orders  (cost=0.00..98877.02 rows=1843 width=0)

This is fixed in current sources (7.3-to-be).  The problem in prior
releases is that current_date is not a constant, and the planner is
not smart enough to understand that it's safe to use an indexscan
anyway.

You can get around this if you need to, using a kluge: make a function
that is marked isCachable and just returns current_date.  The isCachable
marking is a complete lie, of course, but as long as you only use the
trick in interactive queries you can get away with it.  (Don't try it in
plgsql, unless you use EXECUTE to prevent caching of the query plan.)

There are related examples and more complete discussion in the archives.

            regards, tom lane

pgsql-general by date:

Previous
From: "Ian Harding"
Date:
Subject: RHDB Explain
Next
From: Patrick Bakker
Date:
Subject: Distributively cache large, read-only lists of data with cache updates