Re: Re: [COMMITTERS] pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold <

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: Re: [COMMITTERS] pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold <
Дата
Msg-id 20160416220439.56ga5ghy4zgt356h@alap3.anarazel.de
обсуждение исходный текст
Ответ на Re: Re: [COMMITTERS] pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold <  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Re: [COMMITTERS] pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold <  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Julien Rouhaud
Дата:
Сообщение: Re: Memory leak in GIN index build
Следующее
От: Noah Misch
Дата:
Сообщение: Re: [BUGS] Breakage with VACUUM ANALYSE + partitions