Postgres Pro
Downloads
Home   >   mailing lists

Re: Delay locking partitions during query execution - Mailing list pgsql-hackers

From Tomas Vondra
Subject Re: Delay locking partitions during query execution
Date
Msg-id 0d50a468-d261-e132-1516-bacbfdd844e7@2ndquadrant.com
Whole thread Raw
In response to Delay locking partitions during query execution  (David Rowley <david.rowley@2ndquadrant.com>)
Responses Re: Delay locking partitions during query execution  (David Rowley <david.rowley@2ndquadrant.com>)
List pgsql-hackers
Tree view 
On 12/3/18 12:42 PM, David Rowley wrote:
> ...
>
> Master: 10000 parts
> 
> $ pgbench -n -f bench.sql -M prepared -T 60 postgres
> tps = 108.882749 (excluding connections establishing)
> tps = 108.245437 (excluding connections establishing)
> 
> delaylock: 10000 parts
> 
> $ pgbench -n -f bench.sql -M prepared -T 60 postgres
> tps = 1068.289505 (excluding connections establishing)
> tps = 1092.797015 (excluding connections establishing)
> 

I'm a bit confused, because I can't reproduce any such speedup. I've
used the attached script that varies the number of partitions (which
worked quite nicely in the INSERT thread), but I'm getting results like
this:

    partitions      0       100     1000   10000
    --------------------------------------------
    master         49      1214      186      11
    patched        53      1225      187      11

So I don't see any significant speedup, for some reason :-(

Before I start digging into this, is there something that needs to be
done to enable it?

regards

-- 
Tomas Vondra                  http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Attachment

pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: Unified logging system for command-line programs
Next
From: Tomas Vondra
Date:
Subject: Re: FETCH FIRST clause PERCENT option