Re: Declarative partitioning grammar

Hannu Krosing <hannu@tm.ee>

From: Hannu Krosing <hannu@tm.ee>
To: Markus Schiltknecht <markus@bluegap.ch>
Cc: Jeff Cohen <jcohen@greenplum.com>, Warren Turkal <turkal@google.com>, Ron Mayer <rm_pg@cheapcomplexdevices.com>, Gavin Sherry <swm@alcove.com.au>, pgsql-hackers@postgresql.org
Date: 2008-01-15T00:39:08Z
Lists: pgsql-hackers
Ühel kenal päeval, E, 2008-01-14 kell 10:49, kirjutas Markus
Schiltknecht:
> Hi,
> 
> Jeff Cohen wrote:
> > We did look at allowing general functions for partitioning and this was 
> > one concern.  The other is that we want to enforce that a row only gets 
> > inserted into a single partition, so we wanted a declarative syntax 
> > where it was relatively easy to check that range and list specifications 
> > don't overlap.
> 
> Why do you need to define a split point so ambiguously at all? Why not 
> just give the DBA exactly *one* place to define the split point?
> 
> I don't think the separation into list, hash and range partitioning is 
> adequate. What is the system supposed to do, if you try to insert a row 
> which doesn't fit any of the values in your list or doesn't fit any of 
> the ranges you defined?

I guess it would go to some "default" partition ?

...

> IMO, a single DDL command should only touch a single split point, i.e. 
> split a table into two partitions, move the split point or remove the 
> split point (joining the partitions again). Those are the only basic 
> commands you need to be able to handle partitioning.

sure, but this can become really tedious for 1024 partitions, not to
mention hard for optimiser.

> Sorry, but for my taste, the proposed grammar is too long per command, 
> not flexible enough and instead ambiguous for split points as well as 
> for constraints. To me it looks like repeating the mistakes of others.

what mistakes ?

-----------------
Hannu