On Tue, May 31, 2016 at 10:09:05PM -0400, Robert Haas wrote: > On Sun, May 29, 2016 at 1:40 AM, Noah Misch <n...@leadboat.com> wrote: > > On Fri, Dec 25, 2015 at 08:08:15PM +0300, Васильев Дмитрий wrote: > >> I suddenly found commit ac1d794 gives up to 3 times performance > >> degradation. > >> > >> I tried to run pgbench -s 1000 -j 48 -c 48 -S -M prepared on 70 CPU-core > >> machine: > >> commit ac1d794 gives me 363,474 tps > >> and previous commit a05dc4d gives me 956,146 > >> and master( 3d0c50f ) with revert ac1d794 gives me 969,265 > > > > [This is a generic notification.] > > > > The above-described topic is currently a PostgreSQL 9.6 open item. Robert, > > since you committed the patch believed to have created it, you own this open > > item. If some other commit is more relevant or if this does not belong as a > > 9.6 open item, please let us know. Otherwise, please observe the policy on > > open item ownership[1] and send a status update within 72 hours of this > > message. Include a date for your subsequent status update. Testers may > > discover new open items at any time, and I want to plan to get them all > > fixed > > well in advance of shipping 9.6rc1. Consequently, I will appreciate your > > efforts toward speedy resolution. Thanks. > > So, the reason this is back on the open items list is that Mithun Cy > re-reported this problem in: > > https://www.postgresql.org/message-id/CAD__OuhPmc6XH=wYRm_+Q657yQE88DakN4=ybh2ovefashk...@mail.gmail.com > > When I saw that, I moved this from CLOSE_WAIT back to open. However, > subsequently, Ashutosh Sharma posted this, which suggests (not > conclusively) that in fact the problem has been fixed: > > https://www.postgresql.org/message-id/cae9k0pkfehvq-zg4mh0bz-zt_oe5pas6dauxrcxwx9kevwc...@mail.gmail.com > > What I *think* is going on here is: > > - ac1d794 lowered performance > - backend_flush_after with a non-zero default lowered performance with > a vengeance > - 98a64d0 repaired the damage done by ac1d794, or much of it, but > Mithun couldn't see it in his benchmarks because backend_flush_after>0 > is so bad
Ashutosh Sharma's measurements do bolster that conclusion. > That could be wrong, but I haven't seen any evidence that it's wrong. > So I'm inclined to say we should just move this open item back to the > CLOSE_WAIT list (adding a link to this email to explain why we did > so). Does that work for you? That works for me. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
