Re: [HACKERS] Runtime Partition Pruning

Поиск
Список
Период
Сортировка
От Alvaro Herrera
Тема Re: [HACKERS] Runtime Partition Pruning
Дата
Msg-id 20180407131803.s2oahtjluonu6jpn@alvherre.pgsql
обсуждение исходный текст
Ответ на Re: [HACKERS] Runtime Partition Pruning  (David Rowley <david.rowley@2ndquadrant.com>)
Ответы Re: [HACKERS] Runtime Partition Pruning  (David Rowley <david.rowley@2ndquadrant.com>)
Список pgsql-hackers
David Rowley wrote:

> It's not exactly wrong but:
> 
> + * are turned into a set of "pruning steps", which are then executed to
> + * produce a set of RTIs of partitions whose bounds satisfy the constraints in
> + * the step.  Partitions not in the set are said to have been pruned.
> 
> It's only prune_append_rel_partitions which is only used for the
> planner's pruning needs that converts the partition indexes to RTIs.
> Would it be better to mention that the output is partition indexes?
> Maybe:
> 
> "which are then executed to produce a set of partition indexes whose
> bounds satisfy the constraints in the step. These partition indexes
> may then be translated into RTIs", or maybe even not mention the RTIs.

Amit had it as "indexes" also in his original.  I wanted to avoid using
the "indexes" word alone, whose meaning is so overloaded.  How about
this?

"... which are then executed to produce a set of partitions (as indexes
of resultRelInfo->part_rels array) that satisfy the constraints in the
step".

Maybe "the boundinfo array" instead of part_rels, which as I understand
also uses the same indexing as the other array, and partprune mostly
works based on boundinfo anyway?

Not mentioning RTIs seems fine.

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


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

Предыдущее
От: Magnus Hagander
Дата:
Сообщение: Re: Bring atomic flag fallback up to snuff
Следующее
От: David Rowley
Дата:
Сообщение: Re: [HACKERS] Runtime Partition Pruning