| From: | Jesper Pedersen <jesper(dot)pedersen(at)redhat(dot)com> |
|---|---|
| To: | Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>, 'Amit Langote' <amitlangote09(at)gmail(dot)com> |
| Cc: | Imai Yoshikazu <yoshikazu_i443(at)live(dot)jp>, "Imai, Yoshikazu" <imai(dot)yoshikazu(at)jp(dot)fujitsu(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Justin Pryzby <pryzby(at)telsasoft(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: speeding up planning with partitions |
| Date: | 2019-03-22 12:14:33 |
| Message-ID: | d1308bbf-57e1-fc61-b6a5-82e119b23e22@redhat.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jesper Pedersen | 2019-03-22 12:20:24 | Re: partitioned tables referenced by FKs |
| Previous Message | Alexander Korotkov | 2019-03-22 12:14:10 | Re: jsonpath |