Re: Should we add GUCs to allow partition pruning to be disabled?

Поиск
Список
Период
Сортировка
От Amit Langote
Тема Re: Should we add GUCs to allow partition pruning to be disabled?
Дата
Msg-id 2b342e89-4fea-0656-9101-9a260dd4eebd@lab.ntt.co.jp
обсуждение исходный текст
Ответ на Re: Should we add GUCs to allow partition pruning to be disabled?  (David Rowley <david.rowley@2ndquadrant.com>)
Список pgsql-hackers
On 2019/03/13 8:28, David Rowley wrote:
> On Wed, 13 Mar 2019 at 04:07, Robert Haas <robertmhaas@gmail.com> wrote:
>> I think it should be added to one of the existing sub-headings.  I
>> suggest adding it to the end of 5.10.1 and rephrasing it so that it
>> makes clearer the distinction between what will happen with
>> inheritance and what will happen with table partitioning, e.g.

+1.

>> When using either declarative partitioning or table inheritance,
>> partitioning hierarchies with more than a few hundred partitions are
>> not currently recommended. Larger partition hierarchies may incur long
>> planning time, and especially in the case of UPDATE and DELETE,
>> excessive memory usage.  When inheritance is used, see also the
>> limitations described in Section 5.10.5, Partitioning and Constraint
>> Exclusion.
> 
> I think I've done that in the attached patch.  However, do think the
> just saying "excessive memory usage" seems strange without prefixing
> it with "can result in" and dropping the "especially".
FWIW, I've gotten used to reading the kind of English that Robert wrote
(meaning it makes perfect sense to me), but wording tweaks you suggest
will work to.

Thanks,
Amit



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

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: What to name the current heap after pluggable storage / what torename?
Следующее
От: Tatsuo Ishii
Дата:
Сообщение: Re: Early WIP/PoC for inlining CTEs