| From: | Mantas Gridinas <mgridinas(at)gmail(dot)com> |
|---|---|
| To: | pgsql-general(at)lists(dot)postgresql(dot)org |
| Subject: | What is the cost of a tx? |
| Date: | 2026-09-09 20:34:50 |
| Message-ID: | CAE9hW8SZdCnpMtXJYE8JnUqqFK_P3kPXn7T+0LrMyPTT9RbDMQ@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
In the current system that i am working on the feature in question
requires between 1 and 4 requests (individual tx) to a read replica for
extra data (assume orm usage where entity b must be fetched if entity a
doesn’t exist ant so on). At scale this ends up being between 250k (best
case) to 1m (worst case) requests per minute. The individual tx setup uses
"read committed” tx mode. I am considering to move those 4 requests into
single transaction to reduce the amount of transactions in general, but
without behavior change there would still be up to 4 individual queries
during that transaction, so database doesn’t really have full information
about what I want from it. Is the logic sound to perform the change or (at
my scale) the overhead is negligible where it doesn’t really matter that
it’s 1 larger transaction that takes 4 time units compared to 4 smaller
transactions that take 1 time unit?
I suspect that using repeatable read would push the change into single tx
direction since I wouldn’t be snapshotting the database per query.
I am also aware that I could just measure the change but sadly I do not
want to test in production, and this question is more about learning about
other’s experiences.
--
// Mantas
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Ron Johnson | 2026-09-09 21:55:12 | Re: What is the cost of a tx? |
| Previous Message | Igor Korot | 2026-09-09 18:17:44 | Optimizing query |