On Wed, Sep 13, 2017 at 7:24 PM, Jesper Pedersen <jesper.peder...@redhat.com> wrote: > I have done a run with this patch on a 2S/28C/56T/256Gb w/ 2 x RAID10 SSD > machine. > > Both for -M prepared, and -M prepared -S I'm not seeing any improvements (1 > to 375 clients); e.g. +-1%.
My test was done on an 8 socket NUMA intel machine, where I could clearly see improvements as posted before. Architecture: x86_64 CPU op-mode(s): 32-bit, 64-bit Byte Order: Little Endian CPU(s): 128 On-line CPU(s) list: 0-127 Thread(s) per core: 2 Core(s) per socket: 8 Socket(s): 8 NUMA node(s): 8 Vendor ID: GenuineIntel CPU family: 6 Model: 47 Model name: Intel(R) Xeon(R) CPU E7- 8830 @ 2.13GHz Stepping: 2 CPU MHz: 1064.000 BogoMIPS: 4266.62 Virtualization: VT-x L1d cache: 32K L1i cache: 32K L2 cache: 256K L3 cache: 24576K NUMA node0 CPU(s): 0,65-71,96-103 NUMA node1 CPU(s): 72-79,104-111 NUMA node2 CPU(s): 80-87,112-119 NUMA node3 CPU(s): 88-95,120-127 NUMA node4 CPU(s): 1-8,33-40 NUMA node5 CPU(s): 9-16,41-48 NUMA node6 CPU(s): 17-24,49-56 NUMA node7 CPU(s): 25-32,57-64 Let me recheck if the improvement is due to NUMA or cache sizes. Currently above machine is not available for me. It will take 2 more days for same. > Although the -M prepared -S case should improve, I'm not sure that the extra > overhead in the -M prepared case is worth the added code complexity. Each tpcb like (-M prepared) transaction in pgbench have 3 updates 1 insert and 1 select statements. There will be more GetSnapshotData calls than the end of the transaction (cached snapshot invalidation). So I think whatever we cache has a higher chance of getting used before it is invalidated in -M prepared. But on worst cases where we have quick write transaction which invalidates cached snapshot before it is reused becomes an overhead. As Andres has suggested previously I need a mechanism to identify and avoid caching for such scenarios. I do not have a right solution for this at present but one thing we can try is just before caching if we see an exclusive request in wait queue of ProcArrayLock we can avoid caching. -- Thanks and Regards Mithun C Y EnterpriseDB: http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
