Re: Should we add GUCs to allow partition pruning to be disabled? - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Should we add GUCs to allow partition pruning to be disabled?
Date
Msg-id CA+TgmoaY_yr4rErxvnq3EPp=PV1nmb_8ocWg6cU5e2796+4TWw@mail.gmail.com
Whole thread Raw
In response to Re: Should we add GUCs to allow partition pruning to be disabled?  (David Rowley <david.rowley@2ndquadrant.com>)
Responses Re: Should we add GUCs to allow partition pruning to be disabled?
List pgsql-hackers
On Tue, Mar 12, 2019 at 7:28 PM David Rowley
<david.rowley@2ndquadrant.com> wrote:
> I think I've done that in the attached patch.

Cool, thanks.

> However, do think the
> just saying "excessive memory usage" seems strange without prefixing
> it with "can result in" and dropping the "especially".  I'm fairly
> used to having my wording debated, so I've left your words in the
> patch.

I'm not direly opposed to that.  I included "especially" so as not to
rule out the possibility that there might be cases other than UPDATE
and DELETE that, in some circumstances, also use a lot of memory.  I
didn't prefix it with "can result in" because I don't think English
grammar requires it to be there.  It would be grammatically correct to
say "Larger partitioning hierarchies may incur long planning time and
excessive memory usage," and I don't think that injecting an
appositive phrase before "excessive memory usage" changes that
calculus.  However, somebody might find your way easier to follow.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


pgsql-hackers by date:

Previous
From: Sergei Kornilov
Date:
Subject: Re: using index or check in ALTER TABLE SET NOT NULL
Next
From: Peter Eisentraut
Date:
Subject: Re: PATCH: Include all columns in default names for foreign keyconstraints.