From: | peter plachta <pplachta(at)gmail(dot)com> |
---|---|
To: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> |
Cc: | Edson Richter <edsonrichter(at)hotmail(dot)com>, pgsql-performance(at)lists(dot)postgresql(dot)org |
Subject: | Re: Read-only connectios optimizatios |
Date: | 2025-01-25 22:12:18 |
Message-ID: | 1321473A-8A9F-4EA0-AC11-1312012623CC@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
You can still block vacuum from running if you have long running (or very aggressive) read transactions. I don’t think they are very helpful or performant from a Postgres engine perspective.
They can be helpful in application development because they will fail if devs attempt any mutations inside read only (from what I recall).
Sent from my iPhone
> On Jan 25, 2025, at 10:01 AM, Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> wrote:
>
> On Sat, 2025-01-25 at 14:55 +0000, Edson Richter wrote:
>> -Connections are established using the jdbc "readonly" attribute.
>>
>> Does PostgreSQL perform any optimization on queries in this scenario to avoid
>> establishing locks? Or are these queries treated like any other?
>
> The only difference that I am aware of is that read-only transactions at the
> SERIALIZABLE isolation level can release predicate locks earlier, which can
> benefit performance.
>
> But I don't think that you need to worry: reading transactions only take an
> ACCESS SHARE lock on tables, which won't conflict with data modifications.
>
> Yours,
> Laurenz Albe
>
>
From | Date | Subject | |
---|---|---|---|
Next Message | frits.hoogland | 2025-01-25 22:42:02 | Re: Any risk or overhead considerations for frequently executing queries against catalog tables? |
Previous Message | peter plachta | 2025-01-25 22:08:29 | Re: Any risk or overhead considerations for frequently executing queries against catalog tables? |