Re: speeding up planning with partitions - Mailing list pgsql-hackers

From David Rowley
Subject Re: speeding up planning with partitions
Date
Msg-id CAKJS1f-Ff2vttn0y1DDD0X1A5wn8hDENSitkocqXBkYvD7_n8w@mail.gmail.com
Whole thread Raw
In response to Re: speeding up planning with partitions  (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>)
List pgsql-hackers
On Fri, 22 Mar 2019 at 20:39, Amit Langote
<Langote_Amit_f8@lab.ntt.co.jp> wrote:
> The problem is that make_partitionedrel_pruneinfo() does some work which
> involves allocating arrays containing nparts elements and then looping
> over the part_rels array to fill values in those arrays that will be used
> by run-time pruning.  It does all that even *before* it has checked that
> run-time pruning will be needed at all, which if it is not, it will simply
> discard the result of the aforementioned work.
>
> Patch 0008 of 0009 rearranges the code such that we check whether we will
> need run-time pruning at all before doing any of the work that's necessary
> for run-time to work.

I had a quick look at the make_partitionedrel_pruneinfo() code earlier
before this patch appeared and I agree that something like this could
be done. I've not gone over the patch in detail though.

-- 
 David Rowley                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services


pgsql-hackers by date:

Previous
From: Michael Banck
Date:
Subject: Re: Progress reporting for pg_verify_checksums
Next
From: Tom Lane
Date:
Subject: Re: Performance issue in foreign-key-aware join estimation