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;
We cannot perform partition exclusion using this type of WHERE clause at
planning time because the CURRENT DATE function is STABLE.
We can decide that some form of partition exclusion is possible, but the
actual partition we access can *only* be decided within the executor.
That necessarily effects the selectivity estimates. The planner can see
we want some data, but it can't tell which data, so it doesn't know
whether we will hit the day with the most data or the date with the
least data.
You've mentioned this a few times, as if its a problem with dynamic
partitioning, yet its clearly an issue for any form of partitioning.
So it seems clear that we need to make partition exclusion work at
executor time, whatever else we do.
--
Simon Riggs
2ndQuadrant http://www.2ndQuadrant.com
---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at
http://www.postgresql.org/about/donate
