Re: Serializable read only deferrable- implications

Поиск
Список
Период
Сортировка
От Michael Lewis
Тема Re: Serializable read only deferrable- implications
Дата
Msg-id CAHOFxGq2uOWmWgog+o6Z76bTcVQ+2cc=0NSftiuoVqrSRGCvWw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Serializable read only deferrable- implications  ("David G. Johnston" <david.g.johnston@gmail.com>)
Список pgsql-general
Sorry for the confusion I caused. The question about connection management and pg bouncer was a distraction and should have been addressed separately.

When having a mixture of OLTP and OLAP on the same primary databases, is there any benefit to declaring long running report type connections as SERIALIZABLE READ ONLY DEFERRABLE in terms of impact on logical or physical replication, autovacuum, etc even if the much heavier OLTP traffic is still running as the default read committed mode?

If the OLAP queries are moved to a physical read replica, I understand from this post ( https://www.cybertec-postgresql.com/en/streaming-replication-conflicts-in-postgresql/ ) that there are chances that a query will be killed on the replica even with hot_standby_feedback is turned on. With them running on the same server, is the main concern (other than load) that vacuum type cleanup is delayed? 

Maybe to sum up- If a long running report type query is run in default "read committed" mode and uses no temp tables / does no writes, would there be a benefit or change in behavior when using SERIALIZABLE READ ONLY DEFERRABLE mode?

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

Предыдущее
От: "J. Roeleveld"
Дата:
Сообщение: Re: Select .... where id not in (....) returns 0 incorrectly
Следующее
От: Mladen Gogala
Дата:
Сообщение: Re: Select .... where id not in (....) returns 0 incorrectly