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

Robert Haas <robertmhaas@gmail.com>

From: Robert Haas <robertmhaas@gmail.com>
To: David Rowley <david.rowley@2ndquadrant.com>
Cc: Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>, Justin Pryzby <pryzby@telsasoft.com>, Alvaro Herrera <alvherre@2ndquadrant.com>, Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2019-03-13T13:10:24Z
Lists: 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


Commits

  1. Tweak partitioning documentation wording

  2. docs: Rework sections on partition pruning/exclusion

  3. Add GUC enable_partition_pruning