From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Peter Geoghegan <pg(at)bowt(dot)ie> |
Cc: | Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: New IndexAM API controlling index vacuum strategies |
Date: | 2021-03-11 16:31:32 |
Message-ID: | CA+TgmoaFEwk3kJ0dvhU7D3+VAw=McoL1FgxjkDYLZGkM-vT4Kg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Mar 9, 2021 at 3:35 PM Peter Geoghegan <pg(at)bowt(dot)ie> wrote:
> Speaking of line pointer bloat (and "irreversible" bloat), I came
> across something relevant today. I believe that this recent patch from
> Matthias van de Meent is a relatively easy way to improve the
> situation:
>
> https://www.postgresql.org/message-id/flat/CAEze2WjgaQc55Y5f5CQd3L%3DeS5CZcff2Obxp%3DO6pto8-f0hC4w%40mail.gmail.com
I agree, but all you need is one long-lived tuple toward the end of
the array and you're stuck never being able to truncate it. It seems
like a worthwhile improvement, but whether it actually helps will be
workload-dependant.
Maybe it'd be OK to allow a much longer array with offsets > some
constant being usable only for HOT. HOT tuples are not indexed, so it
might be easier to rearrange things to allow compaction of the array
if it does happen to get fragmented. But I'm not sure it's OK to
relocate even a HOT tuple to a different TID. Can someone, perhaps
even just the user, still have a reference to the old one and care
about us invalidating it? Maybe. But even if not, I'm not sure this
helps much with the situation you're concerned about, which involves
non-HOT tuples.
--
Robert Haas
EDB: http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Dean Rasheed | 2021-03-11 16:31:44 | Re: pgbench - add pseudo-random permutation function |
Previous Message | Andrey Borodin | 2021-03-11 16:28:26 | Re: Disallow cancellation of waiting for synchronous replication |