On Fri, Oct 28, 2016 at 3:53 AM, Amit Langote <langote_amit...@lab.ntt.co.jp> wrote: > [ new patches ]
Reviewing 0006: This patch seems scary. I sort of assumed from the title -- "Teach a few places to use partition check quals." -- that this was an optional thing, some kind of optimization from which we could reap further advantage once the basic infrastructure was in place. But it's not that at all. It's absolutely necessary that we do this, or data integrity is fundamentally compromised. How do we know that we've found all of the places that need to be taught about these new, uncatalogued constraints? I'm feeling fairly strongly like you should rewind and make the partitioning constraints normal catalogued constraints. That's got a number of advantages, most notably that we can be sure they will be properly enforced by the entire system (modulo existing bugs, of course). Also, they'll show up automatically in tools like psql's \d output, pgAdmin, and anything else that is accustomed to being able to find constraints in the catalog. We do need to make sure that those constraints can't be dropped (or altered?) inappropriately, but that's a relatively small problem. If we stick with the design you've got here, every client tool in the world needs to be updated, and I'm not seeing nearly enough advantage in this system to justify that kind of upheaval. In fact, as far as I can see, the only advantage of this approach is that when the insert arrives through the parent and is routed to the child by whatever tuple-routing code we end up with (I guess that's what 0008 does), we get to skip checking the constraint, saving CPU cycles. That's probably an important optimization, but I don't think that putting the partitioning constraint in the catalog in any way rules out the possibility of performing that optimization. It's just that instead of having the partitioning excluded-by-default and then sometimes choosing to include it, you'll have it included-by-default and then sometimes choose to exclude it. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers