On Wed, Jun 7, 2017 at 2:08 AM, Jeevan Ladhe <jeevan.la...@enterprisedb.com> wrote: [...] >> >> The code in check_default_allows_bound() to check whether the default >> partition >> has any rows that would fit new partition looks quite similar to the code >> in >> ATExecAttachPartition() checking whether all rows in the table being >> attached >> as a partition fit the partition bounds. One thing that >> check_default_allows_bound() misses is, if there's already a constraint on >> the >> default partition refutes the partition constraint on the new partition, >> we can >> skip the scan of the default partition since it can not have rows that >> would >> fit the new partition. ATExecAttachPartition() has code to deal with a >> similar >> case i.e. the table being attached has a constraint which implies the >> partition >> constraint. There may be more cases which check_default_allows_bound() >> does not >> handle but ATExecAttachPartition() handles. So, I am wondering whether >> it's >> better to somehow take out the common code into a function and use it. We >> will >> have to deal with a difference through. The first one would throw an error >> when >> finding a row that satisfies partition constraints whereas the second one >> would >> throw an error when it doesn't find such a row. But this difference can be >> handled through a flag or by negating the constraint. This would also take >> care >> of Amit Langote's complaint about foreign partitions. There's also another >> difference that the ATExecAttachPartition() queues the table for scan and >> the >> actual scan takes place in ATRewriteTable(), but there is not such queue >> while >> creating a table as a partition. But we should check if we can reuse the >> code to >> scan the heap for checking a constraint. >> >> In case of ATTACH PARTITION, probably we should schedule scan of default >> partition in the alter table's work queue like what >> ATExecAttachPartition() is >> doing for the table being attached. That would fit in the way alter table >> works. > > > I am still working on this. > But, about your comment here: > "if there's already a constraint on the default partition refutes the > partition > constraint on the new partition, we can skip the scan": > I am so far not able to imagine such a case, since default partition > constraint > can be imagined something like "minus infinity to positive infinity with > some finite set elimination", and any new non-default partition being added > would simply be a set of finite values(at-least in case of list, but I think > range > should not also differ here). Hence one cannot imply the other here. > Possibly, > I might be missing something that you had visioned when you raised the flag, > please correct me if I am missing something. >
IIUC, default partition constraints is simply NOT IN (<values of all other sibling partitions>). If constraint on the default partition refutes the new partition's constraints that means we have overlapping partition, and perhaps error. Regards, Amul -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
