2010/10/7 Stephen Frost <sfrost@snowman.net>:
> * Vincenzo Romano (vincenzo.romano@notorand.it) wrote:
>> 2010/10/7 Stephen Frost <sfrost@snowman.net>:
>> > * Vincenzo Romano (vincenzo.romano@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