Re: Serializable read only deferrable- implications - Mailing list pgsql-general

From Michael Lewis
Subject Re: Serializable read only deferrable- implications
Date
Msg-id CAHOFxGq2uOWmWgog+o6Z76bTcVQ+2cc=0NSftiuoVqrSRGCvWw@mail.gmail.com
Whole thread Raw
In response to Re: Serializable read only deferrable- implications  ("David G. Johnston" <david.g.johnston@gmail.com>)
List 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 by date:

Previous
From: "J. Roeleveld"
Date:
Subject: Re: Select .... where id not in (....) returns 0 incorrectly
Next
From: Mladen Gogala
Date:
Subject: Re: Select .... where id not in (....) returns 0 incorrectly