Re: Table Partitioning, Part 1

Simon Riggs <simon(at)2ndquadrant(dot)com> writes:
> 1. Embellish inheritance or separate infrastructure?

> It seems prudent to avoid building on that foundation, even though we
> may decide to use some similar approaches.

I disagree. The code is there, it could use work, and what you are
basically proposing is to duplicate both the existing work and much
of the improvement it needs.

> 2. Individual Relations explicitly in the plan or MultiRelation plan
> nodes? (i.e. is a SeqScan of a Partitioned Table one Node or many
> nodes?)

This one is so obvious it hardly requires any discussion. You cannot
have intelligent planning if you fold everything into a single plan
node. I just finished getting rid of a similarly bad decision in the
context of indexscan planning (ie, a hardwired approach to OR logic)
--- let's not make that mistake again.

> 5. Constraints or specific Partitioning syntax?

> Partition Elimination relies upon being able to prove at execution time

You mean plan time.

> that two clauses in a query restriction are always false when taken
> together.

We already have a reasonably decent implementation of such proving for
partial-index predicate handling. I see no reason not to use that.
So I don't agree with the idea of special-purpose syntax or logic.

regards, tom lane