Re: Summary and Plan for Hot Standby

Поиск
Список
Период
Сортировка
От Heikki Linnakangas
Тема Re: Summary and Plan for Hot Standby
Дата
Msg-id 4B06EAE2.6090206@enterprisedb.com
обсуждение исходный текст
Ответ на Re: Summary and Plan for Hot Standby  (Greg Stark <gsstark@mit.edu>)
Список pgsql-hackers
Greg Stark wrote:
> From discussions in the bar it sounds like this was actually a false
> start however as the RecentGlobalXmin in the backend doing the split
> could be less aggressive than the RecentGlobalXmin used by some other
> backend to hit the hint bits leading to inconsistent results :(

Yeah, RecentGlobalXmin was wrong, it's not used at the moment.

> I'm leaning towards having the backend actually go fetch all the
> xmin/xmaxes of the pointers being pruned. It ought to be possible to
> skip that check in any database with no live snapshots so recovery
> performance would be unaffected on replicas not actively being used in
> hot mode.

Hmm, I have always been thinking that it would be detrimental to
performance to go fetch the xmin/xmaxes, but maybe it indeed wouldn't be
so bad if you could optimize the common case where there's no snapshots
in the standby. Also, if you have a very busy table where a lot of
tuples are killed, many of the heap pages will probably be in cache.

--  Heikki Linnakangas EnterpriseDB   http://www.enterprisedb.com


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

Предыдущее
От: Andreas Pflug
Дата:
Сообщение: Re: Prettification versus dump safety
Следующее
От: Heikki Linnakangas
Дата:
Сообщение: Re: [COMMITTERS] pgsql: /home/peter/commit-msg