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

Поиск
Список
Период
Сортировка
От Justin Pryzby
Тема Re: Should we add GUCs to allow partition pruning to be disabled?
Дата
Msg-id 20190412022427.GQ6952@telsasoft.com
обсуждение исходный текст
Ответ на Re: Should we add GUCs to allow partition pruning to be disabled?  (David Rowley <david.rowley@2ndquadrant.com>)
Список pgsql-hackers
On Fri, Apr 12, 2019 at 02:01:39PM +1200, David Rowley wrote:
> On Thu, 11 Apr 2019 at 17:40, Justin Pryzby <pryzby@telsasoft.com> wrote:
> > I tweaked this patch some more (sorry):
> >  - remove "especially";
> 
> I think that likely needs to be kept for the PG11 version. I was
> hoping it was stop a casual tester testing a SELECT and seeing that
> it's not so bad only to find later that UPDATE/DELETE OOMs.

With "especially", it reads as if "excessive memory usage" might happen for
SELECT, and it'll be additionally worse for UPDATE/DELETE.

Without "especially", it makes "excessive RAM use" apply only to UPDATE/DELETE,
which I think is what's intended.

|Larger partition hierarchies may incur long planning time, and [especially] in
|the case of <command>UPDATE</command> and <command>DELETE</command>, excessive
|memory usage.

I think as long as UPDATE/DELETE are specifically mentioned, that would handle
your concern.  If I were to suggest an alternative:

|Larger partition hierarchies may incur long planning time; and, in
|the case of <command>UPDATE</command> and <command>DELETE</command>, may also
|incur excessive memory usage.

..after which I'll stop wrestling with words.

Justin



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

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: How to include the header files effectively
Следующее
От: "Jamison, Kirk"
Дата:
Сообщение: Minor fix in reloptions.c comments