| From: | Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com> |
|---|---|
| To: | David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Delay locking partitions during query execution |
| Date: | 2019-01-03 13:40:39 |
| Message-ID: | 0d50a468-d261-e132-1516-bacbfdd844e7@2ndquadrant.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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 | Content-Type | Size |
|---|---|---|
| select.sql | application/sql | 60 bytes |
| run-select.sh | application/x-shellscript | 1002 bytes |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tomas Vondra | 2019-01-03 13:51:43 | Re: FETCH FIRST clause PERCENT option |
| Previous Message | Peter Eisentraut | 2019-01-03 13:28:51 | Re: Unified logging system for command-line programs |