From: | Justin Pryzby <pryzby(at)telsasoft(dot)com> |
---|---|
To: | David Rowley <david(dot)rowley(at)2ndquadrant(dot)com> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Should we add GUCs to allow partition pruning to be disabled? |
Date: | 2019-04-12 02:24:28 |
Message-ID: | 20190412022427.GQ6952@telsasoft.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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(at)telsasoft(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Jamison, Kirk | 2019-04-12 02:41:37 | Minor fix in reloptions.c comments |
Previous Message | Alvaro Herrera | 2019-04-12 02:22:56 | Re: How to include the header files effectively |