On Thu, Sep 21, 2017 at 12:08 PM, Alexander Korotkov < a.korot...@postgrespro.ru> wrote:
> On Mon, Sep 18, 2017 at 12:41 PM, Daniel Gustafsson <dan...@yesql.se> > wrote: > >> > On 16 Sep 2017, at 01:51, Alexander Korotkov <a.korot...@postgrespro.ru> >> wrote: >> > >> > On Tue, Sep 5, 2017 at 2:47 PM, Daniel Gustafsson <dan...@yesql.se >> <mailto:dan...@yesql.se>> wrote: >> > > On 04 Apr 2017, at 14:58, David Steele <da...@pgmasters.net <mailto: >> da...@pgmasters.net>> wrote: >> > > >> > > On 4/4/17 8:55 AM, Alexander Korotkov wrote: >> > >> On Mon, Apr 3, 2017 at 9:58 PM, Andres Freund <and...@anarazel.de >> <mailto:and...@anarazel.de> >> > >> >> > >> I'm inclined to push this to the next CF, it seems we need a lot >> more >> > >> benchmarking here. >> > >> >> > >> No objections. >> > > >> > > This submission has been moved to CF 2017-07. >> > >> > This CF has now started (well, 201709 but that’s what was meant in >> above), can >> > we reach closure on this patch in this CF? >> > >> > During previous commitfest I come to doubts if this patch is really >> needed when same effect could be achieved by another (perhaps random) >> change of alignment. The thing I can do now is to retry my benchmark on >> current master and check what effect this patch has now. >> >> Considering this I’ll mark this as Waiting on Author, in case you come to >> conclusion that another patch is required then we’ll bump to a return >> status. >> > > I've made some read-only benchmarking. There is clear win in this case. > The only point where median of master is higher than median of patched > version is 40 clients. > > In this point observations are following: > master: 982432 939483 932075 > pgxact-align: 913151 921300 938132 > So, groups of observations form the overlapping ranges, and this anomaly > can be explained by statistical error. > > I'm going to make some experiments with read-write and mixed workloads too. > I've made benchmarks with two more workloads. scalability-rw.png – read-write tcpb-like workload (pgbench default) scalability-rrw.png – 90% read-only transactions 10% read-write transactions (-btpcb-like@1 -bselect-only@9) It became clear that this patch causes regression. On pure read-write workload, it's not so evident due to high variability of observations. However, on mixed workload it's very clear regression. I would be ridiculous to consider patch which improves read-only performance but degrades read-write performance in nearly same degree. Thus, this topic needs more investigation if it's possible to at least get the same benefit on read-only workload without penalty on read-write workload (ideally read-write workload should benefit too). I'm going to mark this patch as "returned with feedback". ------ Alexander Korotkov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
