2010/10/7 Stephen Frost <sfr...@snowman.net>: > * Vincenzo Romano (vincenzo.rom...@notorand.it) wrote: >> 2010/10/7 Stephen Frost <sfr...@snowman.net>: >> > * Vincenzo Romano (vincenzo.rom...@notorand .it) wrote: >> > The problem is that CHECK conditions can contain just about anything, >> > hence the planner needs to deal with that possibility. >> >> Not really. For partitioning there would be some constraints as you >> have in the DEFAULT values. > > How do we know when it's partitioning and not a CHECK constraint being > used for something else..?
Why asking? You don't need to tell them apart. "Just" parse the expression, extract the metadata to be used when the expression need to be evaluated. Being it a "plain" CHECK constraint or something for the partition management would then be irrelevant. > I'll tell you- through the user using > specific partitioning DDL statements. That could be the next step, once the underlying stuff is already in place. >> Consuming computing resources at DDL-time should be OK if that will >> lead to big savings at DML-time (run-time), my opinion. It'd be just like >> compile time optimizations. > > CHECK constraints, inheiritance, etc, are general things which can be > used for more than just partitioning. Abusing them to go through tons > of extra gyrations to make the specific partitioning case faster at DML > time (if that's really even possible... I'm not convinced you could > make it bullet-proof) isn't a good approach. At the moment I'm not interested in particular cases. I think that CHECK constraints (as well as partial indexes expressions) should be handled in a more effective way. Better partitioning (both for tables and indexes) would be a side effect. Thanks for the insights. > Thanks, > > Stephen > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > > iEYEARECAAYFAkyt5CAACgkQrzgMPqB3kijAUACfd9QcB00Nic6mSwWmwoXABc4p > kBoAnAijF39ZTFOGjpk1CN/8/I3Tj9HI > =C8G/ > -----END PGP SIGNATURE----- -- Vincenzo Romano at NotOrAnd Information Technologies Software Hardware Networking Training Support Security -- NON QVIETIS MARIBVS NAVTA PERITVS -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
