On 2013-06-27 14:42:26 -0400, Tom Lane wrote:
> Shaun Thomas <sthomas@xxxxxxxxxxxxxxxx> writes:
> > On 06/27/2013 12:42 PM, Dave Johansen wrote:
> >> Or what about something like DATE_TRUNC("DAY", now())? Or would that run
> >> into the same optimization/planner problems as CURRENT_DATE?
>
> > Same issue. This seems to work, though I'm not entirely sure of the
> > implications:
>
> > UPDATE pg_proc
> > SET provolatile = 'i'
> > WHERE proname = 'date_in';
>
> That will break things: CURRENT_DATE will then be equivalent to just
> writing today's date as a literal.
>
> It's conceivable that it wouldn't break any scenario that you personally
> care about, if you never use CURRENT_DATE in any view, rule, column
> default expression, or cached plan; but it seems mighty risky from here.
> I don't see any very good solution to your problem within the current
> approach to partitioning, which is basically theorem-proving. That
> proof engine has no concept of time passing, let alone the sort of
> detailed knowledge of the semantics of this particular function that
> would allow it to conclude "if CURRENT_DATE > '2013-06-20' is true now,
> it will always be so in the future as well".
Couldn't we at least significantly improve on the status quo by
detecting we're currently planning a query that's only going to be
executed once (because it's directly executed or because were planning a
onetime plan for specific parameters) and inline stable functions before
doing the theorem proving?
Maybe I am missing something here?
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
