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

From Amit Langote
Subject Re: speeding up planning with partitions
Date
Msg-id 70d7a3c7-0ab0-f814-09dd-da21034d5611@lab.ntt.co.jp
Whole thread Raw
In response to RE: speeding up planning with partitions  ("Imai, Yoshikazu" <imai.yoshikazu@jp.fujitsu.com>)
Responses RE: speeding up planning with partitions
List pgsql-hackers
Imai-san,

On 2019/01/28 10:44, Imai, Yoshikazu wrote:
> On Thu, Jan 24, 2019 at 6:10 AM, Imai, Yoshikazu wrote:
>> updating partkey case:
>>
>> part-num  master     0001     0002     0003     0004
>> 1        8215.34  7924.99  7931.15  8407.40  8475.65
>> 2        7137.49  7026.45  7128.84  7583.08  7593.73
>> 4        5880.54  5896.47  6014.82  6405.33  6398.71
>> 8        4222.96  4446.40  4518.54  4802.43  4785.82
>> 16       2634.91  2891.51  2946.99  3085.81  3087.91
>> 32        935.12  1125.28  1169.17  1199.44  1202.04
>> 64        352.37   405.27   417.09   425.78   424.53
>> 128       236.26   310.01   307.70   315.29   312.81
>> 256        65.36    86.84    87.67    84.39    89.27
>> 512        18.34    24.84    23.55    23.91    23.91
>> 1024        4.83     6.93     6.51     6.45     6.49
> 
> I also tested with non-partitioned table case.
> 
> updating partkey case:
> 
> part-num  master     0001     0002     0003     0004
> 0        10956.7  10370.5  10472.6  10571.0  10581.5
> 1        8215.34  7924.99  7931.15  8407.40  8475.65 
> ...
> 1024        4.83     6.93     6.51     6.45     6.49
> 
> 
> In my performance results, it seems update performance degrades in non-partitioned case with v17-patch applied.
> But it seems this degrades did not happen at v2-patch.
> 
> On Thu, Aug 30, 2018 at 1:45 AM, Amit, Langote wrote:
>> UPDATE:
>>
>> nparts  master    0001    0002   0003
>> ======  ======    ====    ====   ====
>> 0         2856    2893    2862   2816
> 
> Does this degradation only occur in my tests? Or if this result is correct, what may causes the degradation?

I re-ran tests with v18 using the following setup [1]:

create table ht (a int, b int) partition by hash (b);
create table ht_0 partition of ht for values with (modulus N, remainder 0);
...
$ cat update-noprune.sql
update ht set a = 0;

pgbench -n -T 60 -f update-noprune,sql

TPS:

nparts  master    0001    0002   0003   0004
======  ======    ====    ====   ====   ====
0       4408      4335    4423   4379   4314
1       3883      3873    3679   3856   4007
2       3495      3476    3477   3500   3627

I can see some degradation for small number of partitions, but maybe it's
just noise?  At least, I don't yet have a systematic explanation for that
happening.

Thanks,
Amit

[1] I changed the compile flags in build scripts to drop
-DCATCACHE_FORCE_RELEASE, which would cause many syscache misses in my
test runs



pgsql-hackers by date:

Previous
From: Tomas Vondra
Date:
Subject: Re: COPY FROM WHEN condition
Next
From: Konstantin Knizhnik
Date:
Subject: Re: [HACKERS] Cached plans and statement generalization