Skip site navigation (1) Skip section navigation (2)

Re: New partitioning WAS: Check constraints on partition parents only?

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: (view raw, whole thread or download thread mbox)
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

In response to

pgsql-hackers by date

Next:From: Robert HaasDate: 2011-07-28 20:42:38
Subject: Re: cheaper snapshots
Previous:From: Hannu KrosingDate: 2011-07-28 20:36:24
Subject: Re: cheaper snapshots

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group