On Wed, Feb 10, 2016 at 3:24 PM, Andres Freund <andres@anarazel.de> wrote:
Could you please also have a look at the influence this has on latency? I think you unfortunately have to look at the per-transaction logs, and then see whether the worst case latencies get better or worse.
I have quickly measured the per transaction latency of one case (I selected below case to find the worst case latency because in this case we are extending by 1000 blocks and data doesn't fits in shared buffer)
Test--2 (big record insert and Data doesn't fits in shared Buffer) ------------------------------------------------------------------ ./psql -d postgres -c "create table test_data(a int, b text)" ./psql -d postgres -c "insert into test_data values(generate_series(1,1000),repeat('x', 1024))" ./psql -d postgres -c "create table data (a int) with(extend_by_blocks=1000)" echo "insert into data select * from test_data;" >> copy_script
base patch(extend 1000) best 23245 3857 worst 236329 382859 Average 190303 35143
I have also attached the pgbench log files patch_1000.tar --> log files with patch extend by 1000 blocks base.tar --> log files with base code
From attached files we can see that very few transactions latency with patch is high(> 300,000) which is expected and that too when we are extensing 1000 blocks, And we base code almost every transaction latency is hight (>200,000) that we can see that best case and average case latency is 1/5 with extend by 1000.