Re: Table Partitioning, Part 1 - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Table Partitioning, Part 1
Date
Msg-id 2472.1115679232@sss.pgh.pa.us
Whole thread Raw
In response to Table Partitioning, Part 1  (Simon Riggs <simon@2ndquadrant.com>)
Responses Re: Table Partitioning, Part 1
Re: Table Partitioning, Part 1
List pgsql-hackers
Simon Riggs <simon@2ndquadrant.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


pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Table Partitioning, Part 1
Next
From: Simon Riggs
Date:
Subject: Re: Table Partitioning, Part 1