On Thu, Mar 08, 2007 at 10:12:30AM +0000, Gregory Stark wrote:
> "Jim Nasby" <[EMAIL PROTECTED]> writes:
> > One possibility would be to require 3 functions for a partitioned table: one
> > accepts the partitioning key and tells you what partition  it's in, one that
> > tells you what the minimum partitioning key for a  partition would be, and 
> > one
> > that tells you what the maximum would be.  If the user supplied those 3
> > functions, I think it would be possibly  to automatically generate code for 
> > the
> > triggers and check  constraints. The min/max partition key functions might
> > allow you to  more efficiently do partition elimination, too.
> But then it would be harder to tell whether a clause implied a given
> partition. That is, if you have a partition constraint of "col OP const" then
> we can test whether a query clause of "col OP2 const2" implies that constraint
> when planning (or actually whether it implies it's false to exclude the
> partition). If you have a constraint like "P1(const)" it'll be pretty hard to
> do much with that.

Well, you could tell what partition 'const' was in; I would think that
plus knowledge about OP2 would allow you to decide what partitions you
need to look at.

There's also nothing to prevent us from also adding the constraints and
using constraint exclusion as well. In fact, I think we'd want to have
the constraints just so we know that a given partition only contains the
data we want it to.
Jim Nasby                                            [EMAIL PROTECTED]
EnterpriseDB      http://enterprisedb.com      512.569.9461 (cell)

---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at


Reply via email to