Jan Urbański wrote:
> o) my main concern is still valid: the design was never agreed upon.
> The approach of using inheritance info for automatic partitioning is, at
> least IMHO, too restricted. Regular INSERTs won't get routed to child
> tables. Data from writable CTEs won't get routed. People wanting to do
> partitioning on something else that constraints are stuffed.
>
Well, this patch does not claim to implement partitioning for Postgres,
it just offers partitioning as an option for COPY (and COPY only) based
on the existing mechanism in Postgres.
I have already participated in lengthy and relatively sterile
discussions on how to implement a full-blown partitioning but we never
reached the beginning of an agreement and it was decided that a
step-by-step approach would be better. I will propose another
implementation of partitioning in COPY once Postgres has another
representation than constraints on child tables to implement it.
> I strongly suspect the patch will get rejected on the grounds of lack of
> community agreement on partitioning, but I'd hate to see your work
> wasted. It's not too late to open a discussion on how automatic
> partitioning could work (or start working out a common proposal with the
> people discussing in the "Syntax for partitioning" thread).
>
This is not my call. Right now the syntax for partitioning does not
change anything to Postgres, it just adds syntactic sugar on top of the
existing implementation. It will not route anything or answer any of the
needs you mentioned in your previous point.
> Marking as Waiting on Author, although I'd really like to see a solid
> design being agreed upon, and then the code.
>
You are asking the wrong person if you want me to lead the partitioning
design discussions. I already tried once and I was unsuccessful. As
nothing as changed I don't see why I would be more successful this time.
Emmanuel
--
Emmanuel Cecchet
Aster Data
Web: http://www.asterdata.com
