Re: On Scalability

From: Vincenzo Romano <vincenzo(dot)romano(at)notorand(dot)it>
To: Stephen Frost <sfrost(at)snowman(dot)net>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: On Scalability
Date: 2010-10-07 15:23:54
Message-ID: AANLkTikME=8pVmsz3-uzVaoeZ_33jmOw61HKm4EKZQOu@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-performance

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Vincenzo Romano 2010-10-07 15:25:31 Re: On Scalability
Previous Message Robert Haas 2010-10-07 15:21:01 Re: security hook on table creation

Browse pgsql-performance by date

  From Date Subject
Next Message Vincenzo Romano 2010-10-07 15:25:31 Re: On Scalability
Previous Message Stephen Frost 2010-10-07 15:15:44 Re: On Scalability