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 по дате отправления: