Re: [PoC] Improve dead tuple storage for lazy vacuum

From: John Naylor <johncnaylorls(at)gmail(dot)com>
To: Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Nathan Bossart <nathandbossart(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com>, Yura Sokolov <y(dot)sokolov(at)postgrespro(dot)ru>
Subject: Re: [PoC] Improve dead tuple storage for lazy vacuum
Date: 2023-12-19 07:36:52
Message-ID: CANWCAZav4kPwd1t6KfL71nbWEpZ3nLtg7AskzkFzgNA3n0EKNw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Dec 19, 2023 at 12:37 PM Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:
>
> On Mon, Dec 18, 2023 at 3:41 PM John Naylor <johncnaylorls(at)gmail(dot)com> wrote:
> > Let's do it in just one place. In TidStoreCreate(), do
> >
> > /* clamp max_bytes to at least the size of the empty tree with
> > allocated blocks, so it doesn't immediately appear full */
> > ts->control->max_bytes = Max(max_bytes, {rt, shared_rt}_memory_usage);
> >
> > Then we can get rid of all the worry about 1MB/2MB, 64kB, 70kB -- all that.
>
> But doesn't it mean that even if we create a shared tidstore with
> small memory, say 64kB, it actually uses 1MB?

This sounds like an argument for controlling the minimum DSA segment
size. (I'm not really in favor of that, but open to others' opinion)

I wasn't talking about that above -- I was saying we should have only
one place where we clamp max_bytes so that the tree doesn't
immediately appear full.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Masahiko Sawada 2023-12-19 08:00:09 Re: Add isCatalogRel in rmgrdesc
Previous Message Jeff Davis 2023-12-19 07:32:30 Re: Change GUC hashtable to use simplehash?