Re: Partitions not Working as Expected

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andres Freund <andres(at)2ndquadrant(dot)com>
Cc: sthomas(at)optionshouse(dot)com, Dave Johansen <davejohansen(at)gmail(dot)com>, bricklen <bricklen(at)gmail(dot)com>, "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Partitions not Working as Expected
Date: 2013-06-27 21:17:55
Message-ID: 654.1372367875@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Andres Freund <andres(at)2ndquadrant(dot)com> writes:
> 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?

I think Haas went down that rabbit hole before you. The current
definition of stable functions is not strong enough to guarantee that a
plan-time evaluation would give the same result as a run-time
evaluation, not even in one-shot-plan cases. The obvious reason why not
is that the planner isn't using the same snapshot that the executor will
use (which is not that easy to change, see his failed patch from a year
or so back). But even if we rejiggered things enough so the query did
use the same snapshot that'd been used for planning, I'm not very
convinced that such an assumption would be valid. The assumptions for
stable functions are pretty weak really.

regards, tom lane

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Tom Lane 2013-06-27 21:44:09 Re: Partitions not Working as Expected
Previous Message Josh Berkus 2013-06-27 21:14:05 Re: Partitions not Working as Expected