Re: Declarative partitioning - Mailing list pgsql-hackers

From Jean-Pierre Pelletier
Subject Re: Declarative partitioning
Date
Msg-id 6fecdc5455863ad2585e3922fdd314e5@mail.gmail.com
Whole thread Raw
In response to Declarative partitioning  (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>)
Responses Re: Declarative partitioning
List pgsql-hackers
Why not based it on "Exclusion Constraint" ?

Most discussions as of late seems to focus on Range overlaps which appeal
(I would think) is that it supports both "equality" and "overlaps", two
popular partitioning schemes.

"Equality" as in "value1 = value2" can be implemented with "range
overlaps"
as "range(value1,value) = range(value,value2)".

I would think that Partitioning schemes can be Declarative, Efficient and
not restricted to Equality and Overlaps as long as all partitions (of a
partitioned table) are using a single partitioning definition expressed
as:
- An Immutable Expression on tuple columns, in the simplest case a single
column
- An Operator, in the simplest case, "equality"

That seems very close to the semantic of "Constraint Exclusion" as
described here:
http://thoughts.davisjeff.com/2010/09/25/exclusion-constraints-are-general
ized-sql-unique/

If partitioning could be based on EC, it would bring these additional
benefits:
- The choice of operator as long as it is boolean. commutative and
Indexable
- The use of Expression/Function and not just bare columns

Jean-Pierre Pelletier



pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: Convert pltcl from strings to objects
Next
From: Jean-Pierre Pelletier
Date:
Subject: Re: Declarative partitioning