Re: On partitioning

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: On partitioning
Дата
Msg-id 25793.1409587177@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: On partitioning  (Greg Stark <stark@mit.edu>)
Ответы Re: On partitioning  (Greg Stark <stark@mit.edu>)
Re: On partitioning  (Andres Freund <andres@2ndquadrant.com>)
Re: On partitioning  (Heikki Linnakangas <hlinnakangas@vmware.com>)
Список pgsql-hackers
Greg Stark <stark@mit.edu> writes:
> On Sun, Aug 31, 2014 at 9:03 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Aside from costing planning time, most likely that would forever prevent
>> us from pushing some types of intelligence about partitioning into the
>> executor.

> How would it affect this calculus if there were partitioned indexes
> which were created on the overall table and guaranteed to exist on
> each partition that the planner could use -- and then possibly also
> per-partition indexes that might exist in addition to those?

That doesn't actually fix the planning-time issue at all.  Either the
planner considers each partition individually to create a custom plan
for it, or it doesn't.

The "push into executor" idea I was alluding to is that we might invent
plan constructs like a ModifyTable node that applies to a whole
inheritance^H^H^Hpartitioning tree and leaves the tuple routing to be
done at runtime.  You're not going to get a plan structure like that
if the planner is building a separate plan subtree for each partition.
        regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: On partitioning
Следующее
От: Haribabu Kommi
Дата:
Сообщение: Re: [BUGS] BUG #9652: inet types don't support min/max