Re: Problem with default partition pruning

On Wed, 7 Aug 2019 at 21:27, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
wrote:

> 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.
>

Understood

My concern was about the additional execution time caused when there would
be no benefit, especially if the algoithmic cost is O(N) or similar (i.e.
worse than O(k))

If people have a default partition, I have no problem in there being
additional execution time in that case only since there is only ever one
default partition.

> > 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.
>

Thanks

--
Simon Riggs http://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Solutions for the Enterprise