| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | Kevin Grittner <kgrittn(at)postgresql(dot)org>, pgsql-hackers(at)postgresql(dot)org |
| Cc: | pgsql-committers(at)postgresql(dot)org |
| Subject: | Re: [COMMITTERS] pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold < |
| Date: | 2016-04-12 17:38:56 |
| Message-ID: | 20160412173856.6jumsz7es5zac42o@alap3.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-committers pgsql-hackers |
On 2016-04-12 16:49:25 +0000, Kevin Grittner wrote:
> On a big NUMA machine with 1000 connections in saturation load
> there was a performance regression due to spinlock contention, for
> acquiring values which were never used. Just fill with dummy
> values if we're not going to use them.
FWIW, I could see massive regressions with just 64 connections.
I'm a bit scared of having an innoccuous sounding option regress things
by a factor of 10. I think, in addition to this fix, we need to actually
solve the scalability issue here to a good degree. One way to do so is
to apply the parts of 0001 in
http://archives.postgresql.org/message-id/20160330230914.GH13305%40awork2.anarazel.de
defining PG_HAVE_8BYTE_SINGLE_COPY_ATOMICITY and rely on that. Another
to apply the whole patch and simply put the lsn in an 8 byte atomic.
- Andres
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Kevin Grittner | 2016-04-12 18:44:00 | Re: pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold < |
| Previous Message | Alvaro Herrera | 2016-04-12 17:31:09 | Re: [COMMITTERS] pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold < |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2016-04-12 17:43:41 | Re: Lets (not) break all the things. Was: [pgsql-advocacy] 9.6 -> 10.0 |
| Previous Message | Alvaro Herrera | 2016-04-12 17:31:09 | Re: [COMMITTERS] pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold < |