Re: Re: [COMMITTERS] pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold < - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Re: [COMMITTERS] pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold <
Date
Msg-id 20160416220439.56ga5ghy4zgt356h@alap3.anarazel.de
Whole thread Raw
In response to Re: Re: [COMMITTERS] pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold <  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Re: [COMMITTERS] pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold <  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On 2016-04-16 17:52:44 -0400, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
> > On 2016-04-16 16:44:52 -0400, Noah Misch wrote:
> >> That is more controversial than the potential ~2% regression for
> >> old_snapshot_threshold=-1.  Alvaro[2] and Robert[3] are okay releasing
> >> that way, and Andres[4] is not.
> 
> > FWIW, I could be kinda convinced that it's temporarily ok, if there'd be
> > a clear proposal on the table how to solve the scalability issue around
> > MaintainOldSnapshotTimeMapping(). Postponing the optimization around
> > something as trivial as a spinlock around reading an LSN is one thing,
> > postponing something we don't know the solution to is anohter.
> 
> The message Noah cited mentions only a 4% regression, but this one
> seems far worse:
> 
> http://www.postgresql.org/message-id/20160413200148.bawmwjdmggbllhha@alap3.anarazel.de
> 
> That's more than a 5X penalty, which seems like it would make the
> feature unusable; unless there is an argument that that's an extreme
> case that wouldn't be representative of most real-world usage.
> Which there may well be; I've not been following this thread carefully.

The 4 % was with the feature disabled (in comparison to before it's
introduction), we're not sure where that's coming from. But the 5x - and
that was just on a mid-sized box - is with the feature enabled.

- Andres



pgsql-hackers by date:

Previous
From: Julien Rouhaud
Date:
Subject: Re: Memory leak in GIN index build
Next
From: Noah Misch
Date:
Subject: Re: [BUGS] Breakage with VACUUM ANALYSE + partitions