Re: Relation extension scalability - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Relation extension scalability
Date
Msg-id 20160202154913.GV8743@awork2.anarazel.de
Whole thread Raw
In response to Re: Relation extension scalability  (Dilip Kumar <dilipbalaut@gmail.com>)
Responses Re: Relation extension scalability
Re: Relation extension scalability
Re: Relation extension scalability
List pgsql-hackers
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



pgsql-hackers by date:

Previous
From: Magnus Hagander
Date:
Subject: Re: Add links to commit fests to patch summary page
Next
From: Andres Freund
Date:
Subject: Re: Relation extension scalability