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

From Jesper Pedersen
Subject Re: speeding up planning with partitions
Date
Msg-id d1308bbf-57e1-fc61-b6a5-82e119b23e22@redhat.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
Hi Amit,

On 3/22/19 3:39 AM, Amit Langote wrote:
> I took a stab at this.  I think rearranging the code in
> make_partitionedrel_pruneinfo() slightly will take care of this.
> 
> 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.
> 

Yeah, this is better :) Increasing number of partitions leads to a TPS 
within the noise level.

Passes check-world.

Best regards,
  Jesper


pgsql-hackers by date:

Previous
From: Alexander Korotkov
Date:
Subject: Re: jsonpath
Next
From: Jesper Pedersen
Date:
Subject: Re: partitioned tables referenced by FKs