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 ---------------------------(end of broadcast)--------------------------- TIP 4: Have you searched our list archives? http://archives.postgresql.org