Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: peter plachta <pplachta@gmail.com>
Mime-Version: 1.0 (1.0)
Subject: Re: Read-only connectios optimizatios
Date: Sat, 25 Jan 2025 14:12:18 -0800
Message-Id: <1321473A-8A9F-4EA0-AC11-1312012623CC@gmail.com>
References: <d1581404ad5169663d985d78262e948ff2877c51.camel@cybertec.at>
Cc: Edson Richter <edsonrichter@hotmail.com>,
 pgsql-performance@lists.postgresql.org
In-Reply-To: <d1581404ad5169663d985d78262e948ff2877c51.camel@cybertec.at>
To: Laurenz Albe <laurenz.albe@cybertec.at>
Archived-At: 
 <https://www.postgresql.org/message-id/1321473A-8A9F-4EA0-AC11-1312012623CC%40gmail.com>
Precedence: bulk

You can still block vacuum from running if you have long running (or very ag=
gressive) read transactions. I don=E2=80=99t think they are very helpful or p=
erformant from a Postgres engine perspective.
They can be helpful in application development because they will fail if dev=
s attempt any mutations inside read only (from what I recall).

Sent from my iPhone

> On Jan 25, 2025, at 10:01=E2=80=AFAM, Laurenz Albe <laurenz.albe@cybertec.=
at> wrote:
>=20
> =EF=BB=BFOn Sat, 2025-01-25 at 14:55 +0000, Edson Richter wrote:
>> -Connections are established using the jdbc "readonly" attribute.
>>=20
>> Does PostgreSQL perform any optimization on queries in this scenario to a=
void
>> establishing locks? Or are these queries treated like any other?
>=20
> The only difference that I am aware of is that read-only transactions at t=
he
> SERIALIZABLE isolation level can release predicate locks earlier, which ca=
n
> benefit performance.
>=20
> But I don't think that you need to worry: reading transactions only take a=
n
> ACCESS SHARE lock on tables, which won't conflict with data modifications.=

>=20
> Yours,
> Laurenz Albe
>=20
>=20