From: Alvaro Herrera <alvherre@2ndquadrant.com>
To: Simon Riggs <simon@2ndquadrant.com>
Cc: Amit Langote <amitlangote09@gmail.com>
Cc: yuzuko <yuzukohosoya@gmail.com>
Cc: shawn wang <shawn.wang.pg@gmail.com>
Cc: Shawn Wang <shawn.wang@highgo.ca>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: Problem with default partition pruning
Date: Wed, 7 Aug 2019 16:27:06 -0400
Message-ID: <20190807202706.GA14015@alvherre.pgsql> (raw)
In-Reply-To: <CANP8+j+tMCY=nEcQeqQam85=uopLBtX-2vHiLD2bbp7iQQUKpA@mail.gmail.com>
On 2019-Aug-07, Simon Riggs wrote:
> I saw your recent commit and it scares me in various places, noted below.
>
> "Commit: Apply constraint exclusion more generally in partitioning"
>
> "This applies particularly to the default partition..."
>
> My understanding of the thread was the complaint was about removing the
> default partition. I would prefer to see code executed just for that case,
> so that people who do not define a default partition are unaffected.
Well, as the commit message noted, it applies to other cases also, not
just the default partition. The default partition just happens to be
the most visible case.
> "So in certain cases
> we're scanning partitions that we don't need to."
>
> Avoiding that has been the subject of months of work.
Well, yes, avoiding that is the point of this commit also: we were
scanning some partitions for some queries, after this patch we're
supposed not to.
> "This has the unwanted side-effect of testing some (most? all?)
> constraints more than once if constraint_exclusion=on. That seems
> unavoidable as far as I can tell without some additional work, but
> that's not the recommended setting for that parameter anyway.
> However, because this imposes additional processing cost for all
> queries using partitioned tables..."
>
> One of the major features of PG12 is the additional performance and
> scalability of partitoning, but we don't seem to have benchmarked the
> effect of this patch on those issues.
>
> Please could we do perf checks, with tests up to 1000s of partitions? And
> if there is a regression, I would vote to revoke this patch or address the
> request in a less general way.
I'll have a look.
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: alvherre@2ndquadrant.com, simon@2ndquadrant.com, amitlangote09@gmail.com, yuzukohosoya@gmail.com, shawn.wang.pg@gmail.com, shawn.wang@highgo.ca, pgsql-hackers@lists.postgresql.org
Subject: Re: Problem with default partition pruning
In-Reply-To: <20190807202706.GA14015@alvherre.pgsql>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox