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 <
|
Список | 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 по дате отправления: