|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|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
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
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
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
|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|