From: | Stephen Frost <sfrost(at)snowman(dot)net> |
---|---|
To: | Vincenzo Romano <vincenzo(dot)romano(at)notorand(dot)it> |
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:15:44 |
Message-ID: | 20101007151544.GW26232@tamriel.snowman.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-performance |
* 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(dot)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..? I'll tell you- through the user using
specific partitioning DDL statements.
> 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.
Thanks,
Stephen
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2010-10-07 15:21:01 | Re: security hook on table creation |
Previous Message | Stephen Frost | 2010-10-07 15:12:44 | Re: On Scalability |
From | Date | Subject | |
---|---|---|---|
Next Message | Vincenzo Romano | 2010-10-07 15:23:54 | Re: On Scalability |
Previous Message | Stephen Frost | 2010-10-07 15:12:44 | Re: On Scalability |