On 2016-01-28 16:53:08 +0530, Dilip Kumar wrote: > test_script: > ------------ > ./psql -d postgres -c "truncate table data" > ./psql -d postgres -c "checkpoint" > ./pgbench -f copy_script -T 120 -c$ -j$ postgres > > Shared Buffer 48GB > Table: Unlogged Table > ench -c$ -j$ -f -M Prepared postgres > > Clients Base patch > 1 178 180 > 2 337 338 > 4 265 601 > 8 167 805
Could you also measure how this behaves for an INSERT instead of a COPY workload? Both throughput and latency. It's quite possible that this causes latency hikes, because suddenly backends will have to wait for one other to extend by 50 pages. You'll probably have to use -P 1 or full statement logging to judge that. I think just having a number of connections inserting relatively wide rows into one table should do the trick. I'm doubtful that anything that does the victim buffer search while holding the extension lock will actually scale in a wide range of scenarios. The copy scenario here probably isn't too bad because the copy ring buffes are in use, and because there's no reads increasing the usagecount of recent buffers; thus a victim buffers are easily found. Thanks, Andres -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
