From: | David Rowley <dgrowleyml(at)gmail(dot)com> |
---|---|
To: | Ahmed Yarub Hani Al Nuaimi <ahmedyarubhani(at)gmail(dot)com> |
Cc: | Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Lock-free compaction. Why not? |
Date: | 2024-07-10 09:49:49 |
Message-ID: | CAApHDvqC8dJtCFAKYqhyKhxB=nttZmVXe71EBAxWj6kfg8RTfw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, 9 Jul 2024 at 16:58, Ahmed Yarub Hani Al Nuaimi
<ahmedyarubhani(at)gmail(dot)com> wrote:
> The thing is, after reading the code a million times, I still don't understand why lock-free (or minimum locking) is such a big problem! Is it that hard to lazily move tuples from one page to the other after defragmenting it lazily?
I think there are a few things to think about. You may have thought of
some of these already.
1. moving rows could cause deadlocking issues. Users might struggle to
accept that some background process is causing their transaction to
rollback.
2. transaction size: How large to make the batches of tuples to move
at once? One transaction sounds much more prone to deadlocking.
3. xid consumption. Doing lots of small transactions to move tuples
could consume lots of xids.
4. moving tuples around to other pages needs indexes to be updated and
could cause index bloat.
For #1, maybe there's something that can be done to ensure it's always
vacuum that's the deadlock victim.
You might be interested in [1]. There's also an older discussion in
[2] that you might find interesting.
David
[1] https://www.postgresql.org/message-id/flat/CAFj8pRDNDOrg90hLMmbo_hiWpgBm%2B73gmWMRUHRkTKwrGnvYJQ%40mail.gmail.com#cc4f8d730d2c5203f53c50260053fec5
[2] https://www.postgresql.org/message-id/flat/CANTTaev-LdgYj4uZoy67catS5SF5u_X-dTHiLH7OKwU6Gv3MFA%40mail.gmail.com
From | Date | Subject | |
---|---|---|---|
Next Message | Dave Page | 2024-07-10 09:55:50 | Re: Should we work around msvc failing to compile tab-complete.c? |
Previous Message | shveta malik | 2024-07-10 09:39:17 | Re: Conflict detection and logging in logical replication |