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 http://www.postgresql.org/about/donate
