Re: Table Partitioning, Part 1

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Table Partitioning, Part 1
Дата
Msg-id 2472.1115679232@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Table Partitioning, Part 1  (Simon Riggs <simon@2ndquadrant.com>)
Ответы Re: Table Partitioning, Part 1  (Simon Riggs <simon@2ndquadrant.com>)
Re: Table Partitioning, Part 1  (Greg Stark <gsstark@mit.edu>)
Список 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 по дате отправления:

Предыдущее
От: Simon Riggs
Дата:
Сообщение: Table Partitioning, Part 1
Следующее
От: Simon Riggs
Дата:
Сообщение: Re: Table Partitioning, Part 1