On 09/14/2016 05:29 PM, Robert Haas wrote:
On Wed, Sep 14, 2016 at 12:55 AM, Dilip Kumar <dilipbal...@gmail.com> wrote:
2. Results
./pgbench -c $threads -j $threads -T 10 -M prepared postgres -f script.sql
scale factor: 300
Clients head(tps) grouplock(tps) granular(tps)
------- --------- ---------- -------
128 29367 39326 37421
180 29777 37810 36469
256 28523 37418 35882
grouplock --> 1) Group mode to reduce CLOGControlLock contention
granular --> 2) Use granular locking model
I will test with 3rd approach also, whenever I get time.
3. Summary:
1. I can see on head we are gaining almost ~30 % performance at higher
client count (128 and beyond).
2. group lock is ~5% better compared to granular lock.
Sure, but you're testing at *really* high client counts here. Almost
nobody is going to benefit from a 5% improvement at 256 clients. You
need to test 64 clients and 32 clients and 16 clients and 8 clients
and see what happens there. Those cases are a lot more likely than
these stratospheric client counts.
Right. My impression from the discussion so far is that the patches only
improve performance with very many concurrent clients - but as Robert
points out, almost no one is running with 256 active clients, unless
they have 128 cores or so. At least not if they value latency more than
throughput.
So while it's nice to improve throughput in those cases, it's a bit like
a tree falling in the forest without anyone around.
regards
--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
