On Tue, 2007-03-06 at 18:31 +0530, NikhilS wrote: > On 3/6/07, Peter Eisentraut <[EMAIL PROTECTED]> wrote: > NikhilS wrote: > > iv) Based on the PRIMARY, UNIQUE, REFERENCES information > specified, > > pass it on to the children tables. > > How will you maintain a primary key in such a table, > considering that > indexes can't span multiple tables? > > We will not (I know its a hard thing to do :) ), the intention is to > use this information from the parent and make it a property of the > child table. This will avoid the step for the user having to manually > specify CREATE INDEX and the likes on all the children tables > one-by-one.
If you know that the constraints on each of the tables is distinct, then building a UNIQUE index on each of the partitions is sufficient to prove that all rows in the combined partitioned table are distinct also. The hard part there is checking that the partition constraints are distinct. If the partition constraints are added one at a time, you can use the predicate testing logic to compare the to-be-added partition's constraint against each of the already added constraints. That becomes an O(N) problem. What is really needed is a data structure that allows range partitions to be accessed more efficiently. This could make adding partitions and deciding in which partition a specific value goes an O(logN) operation. -- Simon Riggs EnterpriseDB http://www.enterprisedb.com ---------------------------(end of broadcast)--------------------------- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly