Re: Table Partitioning, Part 1

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org, bizgres-general <bizgres-general(at)pgfoundry(dot)org>
Subject: Re: Table Partitioning, Part 1
Date: 2005-05-09 22:53:52
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

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

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2005-05-09 23:16:17 Re: Table Partitioning, Part 1
Previous Message Simon Riggs 2005-05-09 22:30:58 Table Partitioning, Part 1