On Thu, Jan 10, 2008 at 07:25:00AM +0000, Simon Riggs wrote:
> On Thu, 2008-01-10 at 03:06 +0100, Gavin Sherry wrote:
> > If the exclusion is executor driven, the planner cannot help but
> > create a seq scan plan. The planner will think you're returning 100X
> > rows when really you end up returning X rows. After that, all
> > decisions made by the planner are totally bogus.
>
> One of the most important queries on large tables is handling
> WHERE Eventdate = CURRENT DATE;
Really? Well, this isn't handled by the current partitioning approach
(i.e., constraint exclusion) so users have worked around it.
>
> We cannot perform partition exclusion using this type of WHERE clause at
> planning time because the CURRENT DATE function is STABLE.
We can do the exact same thing -- if it's a direction people want to
take. In fact, we can do it better/faster because once we've evaluated one
partition we know that there are no others to evaluate.
> So it seems clear that we need to make partition exclusion work at
> executor time, whatever else we do.
One example doesn't make the rule. Most people doing range partitioning
are going to be doing either specific dates or date ranges -- i.e.,
constants or things that can be folded to constants by the planner. At
least, that's what I've seen.
Thanks,
Gavin