Re: Relation extension scalability

On Wed, Feb 10, 2016 at 3:24 PM, Andres Freund <andres(at)anarazel(dot)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

shared_buffers=512B -c max_wal_size=20GB -c checkpoint_timeout=10min
./pgbench -c 8 -j 8 -f copy_script -T -l 120 postgres

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.

--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com