Date: Thu, 27 Jun 2013 22:43:17 +0200
From: Andres Freund <andres@2ndquadrant.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: sthomas@optionshouse.com, Dave Johansen <davejohansen@gmail.com>,
 bricklen <bricklen@gmail.com>,
 "pgsql-performance@postgresql.org" <pgsql-performance@postgresql.org>
Subject: Re: Partitions not Working as Expected
Message-ID: <20130627204317.GP1254@alap2.anarazel.de>
References: <51CC652F.3010304@optionshouse.com>
 <A76B25F2823E954C9E45E32FA49D70EC1BBD8EEA@mail.corp.perceptron.com>
 <51CC73B6.2050406@optionshouse.com>
 <CAGrpgQ_3pCLt3CJnap3z+nWe3-Q=A3sMH7OKP0sUeo79kViD8w@mail.gmail.com>
 <CAAcYxUfCaYbpAv-sQaNGKEVK2UZA1BtL87jM8LBd81ZomaLUuA@mail.gmail.com>
 <51CC8160.2080905@optionshouse.com>
 <27533.1372358546@sss.pgh.pa.us>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <27533.1372358546@sss.pgh.pa.us>
Precedence: bulk
Sender: pgsql-performance-owner@postgresql.org

On 2013-06-27 14:42:26 -0400, Tom Lane wrote:
> Shaun Thomas <sthomas@optionshouse.com> 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@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance