RE: Speed up transaction completion faster after many relations areaccessed in a transaction - Mailing list pgsql-hackers

From Imai, Yoshikazu
Subject RE: Speed up transaction completion faster after many relations areaccessed in a transaction
Date
Msg-id 0F97FA9ABBDBE54F91744A9B37151A512BD54D@g01jpexmbkw24
Whole thread Raw
In response to Re: Speed up transaction completion faster after many relations areaccessed in a transaction  (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>)
List pgsql-hackers
On Fri, Apr 5, 2019 at 1:31 AM, Amit Langote wrote:
> On 2019/04/05 5:42, Peter Eisentraut wrote:
> > On 2019-04-04 06:58, Amit Langote wrote:
> >> Also, since the "speed up partition planning" patch went in
> >> (428b260f8), it might be possible to see the performance boost even
> >> with the partitioning example you cited upthread.
> >
> > I can't detect any performance improvement with the patch applied to
> > current master, using the test case from Yoshikazu Imai (2019-03-19).
> 
> I was able to detect it as follows.
> 
> * partitioned table setup:
> 
> $ cat ht.sql
> drop table ht cascade;
> create table ht (a int primary key, b int, c int) partition by hash (a);
> select 'create table ht' || x::text || ' partition of ht for values with
> (modulus 8192, remainder ' || (x)::text || ');' from generate_series(0,
> 8191) x;
> \gexec
> 
> * pgbench script:
> 
> $ cat select.sql
> \set param random(1, 8192)
> select * from ht where a = :param
> 
> * pgbench (5 minute run with -M prepared)
> 
> pgbench -n -M prepared -T 300 -f select.sql
> 
> * tps:
> 
> plan_cache_mode = auto
> 
>    HEAD: 1915 tps
> Patched: 2394 tps
> 
> plan_cache_mode = custom (non-problematic: generic plan is never created)
> 
>    HEAD: 2402 tps
> Patched: 2393 tps

Amit-san, thanks for testing this.

I also re-ran my tests(3/19) with HEAD(413ccaa) and HEAD(413ccaa) + patched, and I can still detect the performance
differencewith plan_cache_mode = auto.
 

Thanks
--
Yoshikazu Imai 


pgsql-hackers by date:

Previous
From: Ashutosh Sharma
Date:
Subject: Re: Server Crash due to assertion failure in _bt_check_unique()
Next
From: Michael Paquier
Date:
Subject: Re: pg_rewind vs superuser