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

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Re: [COMMITTERS] pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold <
Дата
Msg-id 5870.1460845626@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Re: [COMMITTERS] pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold <  (Andres Freund <andres@anarazel.de>)
Ответы Re: Re: [COMMITTERS] pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold <  (Andres Freund <andres@anarazel.de>)
Список pgsql-hackers
Andres Freund <andres@anarazel.de> writes:
> On 2016-04-16 17:52:44 -0400, Tom Lane wrote:
>> 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.

128 processors is a mid-sized box?  Or if you didn't have 128 processors,
why are you testing "-c 128 -j 128" cases?

More seriously, the complaints here seem to center on performance in a
read-only workload; but I don't actually see why you'd want to turn on
this feature in a read-only, or even read-mostly, workload.  It exists for
the benefit of people who are trying to keep their pg_xlog/ directories
reasonably sized, no?  That doesn't sound very read-only-ish to me.
        regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Noah Misch
Дата:
Сообщение: Re: [BUGS] Breakage with VACUUM ANALYSE + partitions
Следующее
От: Andres Freund
Дата:
Сообщение: Re: [BUGS] Breakage with VACUUM ANALYSE + partitions