On Thu, Jan 10, 2008 at 09:30:10PM +0000, Simon Riggs wrote:
> > > 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.
>
> Lost you completely here. I'm explaining to you that *nobody* can solve
> those problems solely at planning time, by definition, so it has to be
> done at execution time. I'm not saying anything about your way, my way.
Sorry, I wasn't clear enough. I was trying to say, if we're going to do
something in the executor (for right or wrong) the declarative approach
can do it too. Since there will be partition bounding information
available, we can do partition selection in the executor (maybe the
planner should tell us to do it).
>
> > > 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.
>
> It's not always true that planning time = execution time.
>
> Using CURRENT DATE to access current day, week, month is common in many
> applications, as is parameterised SQL for higher transaction rate apps.
>
> We we can't re-write all the SQL, so we need to make it work.
>
> I think if you demand a full function implementation of partitioning,
> you'd better take into account *all* of the requirements.
Okay. As I said above, nothing in declarative partitioning rules out
partition selection with stable functions. So, we lets do it, assuming
everyone else thinks it is a good idea.
Thanks,
Gavin