| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Aidan Van Dyk <aidan(at)highrise(dot)ca> |
| Cc: | Josh Berkus <josh(at)agliodbs(dot)com>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: New partitioning WAS: Check constraints on partition parents only? |
| Date: | 2011-07-28 20:41:43 |
| Message-ID: | 5094.1311885703@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Aidan Van Dyk <aidan(at)highrise(dot)ca> writes:
> On Thu, Jul 28, 2011 at 12:53 PM, Josh Berkus <josh(at)agliodbs(dot)com> wrote:
>> Second, the key-based partitioning I described would actually be
>> preferred to what you describe by a lot of users I know, because it's
>> even simpler than what you propose, which means less contract DBA work
>> they have to pay for to set it up.
> But part of the desire for "simple partitioning" is to make sure the
> query planner and execution knows about partitions, can do exclude
> unnecessary partitions from queries. If partion knowledge doesn't
> help the query plans, its not much use excpt to reduce table size,
> which isn't a hard task with the current inheritance options.
> But if the "partition" selection is an opaque "simple key" type
> function, you haven't given the planner/executor anything better to be
> able to pick partitions for queries, unless the query is an exact "key
> =" type of operation.
Right. I think the *minimum* requirement for intelligent planning is
that the partitioning be based on ranges of a btree-sortable type.
Single values is a special case of that (for discrete types anyway),
but it doesn't cover enough cases to be the primary definition.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2011-07-28 20:42:38 | Re: cheaper snapshots |
| Previous Message | Hannu Krosing | 2011-07-28 20:36:24 | Re: cheaper snapshots |