From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Kevin Grittner <kgrittn(at)gmail(dot)com> |
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 17:41:04 |
Message-ID: | 20160503174104.tk7oz4akwbeqsmuq@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2016-05-03 11:46:23 -0500, Kevin Grittner wrote:
> > 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.)
They're from after the spinlock issue was resolved. Before that the
issue was a lot worse (see mail linked two messages upthread).
I'm pretty sure that I said that somewhere else at least once: But to be
absolutely clear, I'm *not* really concerned with the performance with
the feature turned off. I'm concerned about the performance with it
turned on.
Andres
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2016-05-03 17:41:31 | Re: ALTER TABLE lock downgrades have broken pg_upgrade |
Previous Message | Andrew Dunstan | 2016-05-03 17:40:37 | Re: ALTER TABLE lock downgrades have broken pg_upgrade |