From: | Kevin Grittner <kgrittn(at)gmail(dot)com> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: what to revert |
Date: | 2016-05-03 16:46:23 |
Message-ID: | CACjxUsPb63TqU1uBc6zW5fsFynUB=BZ8NbFp6E=jK9qA7twibg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, May 3, 2016 at 11:22 AM, Andres Freund <andres(at)anarazel(dot)de> wrote:
> The issue with 0 v. -1 (and 0 vs. > 0 makes a big performance
> difference, so it's not that surprising to interpret numbers that way)
... if you fail to read the documentation of the feature or the
code implementing it before testing.
> was immediately addressed by another round of benchmarks after you
> pointed it out.
Which showed a 4% maximum hit before moving the test for whether it
was "off" inline. (I'm not clear from the posted results whether
that was before or after skipping the spinlock when the feature was
off.) All tests that I have done and that others have done (some
on big NUMA machines) and shared with me show no regression now. I
haven't been willing to declare victory on that basis without
hearing back from others who were able to show a regression before.
If there is still a regression found when "off", there is one more
test of old_snapshot_threshold which could easily be shifted
in-line; it just seems unnecessary given the other work done in
that area unless there is evidence that it is really needed.
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2016-05-03 16:48:18 | Re: old_snapshot_threshold's interaction with hash index |
Previous Message | Robert Haas | 2016-05-03 16:40:50 | Re: what to revert |