From: | Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com> |
---|---|
To: | Nathan Bossart <nathandbossart(at)gmail(dot)com> |
Cc: | "Burd, Greg" <gregburd(at)amazon(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Expanding HOT updates for expression and partial indexes |
Date: | 2025-02-11 18:03:11 |
Message-ID: | CAEze2WiT_dzxYpUhf1WBdJiT2hEfmh5F-+GugKaruMHQmiaYXg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, 11 Feb 2025 at 00:20, Nathan Bossart <nathandbossart(at)gmail(dot)com> wrote:
>
> On Mon, Feb 10, 2025 at 06:17:42PM +0100, Matthias van de Meent wrote:
> > I have serious doubts about the viability of any proposal working to
> > implement PHOT/WARM in PostgreSQL, as they seem to have an inherent
> > nature of fundamentally breaking the TID lifecycle:
> > [... concerns]
>
> I share your concerns, but I don't think things are as dire as you suggest.
> For example, perhaps we put a limit on how long a PHOT chain can be, or
> maybe we try to detect update patterns that don't work well with PHOT.
> Another option could be to limit PHOT updates to only when the same set of
> indexed columns are updated or when <50% of the indexed columns are
> updated. These aren't fully fleshed-out ideas, of course, but I am at
> least somewhat optimistic we could find appropriate trade-offs.
Yes, there are methods which could limit the overhead. But I'm not
sure there are cheap-enough designs which would make PHOT a
universally good choice (i.e. not tunable with guc/table option),
considering its significantly larger un-reclaimable storage overhead
vs HOT.
Kind regards,
Matthias van de Meent.
From | Date | Subject | |
---|---|---|---|
Next Message | Nathan Bossart | 2025-02-11 18:11:30 | Re: describe special values in GUC descriptions more consistently |
Previous Message | Sami Imseih | 2025-02-11 18:00:27 | Re: pg_stat_statements and "IN" conditions |