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

From: Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>
To: John Naylor <john(dot)naylor(at)enterprisedb(dot)com>
Cc: 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>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PoC] Improve dead tuple storage for lazy vacuum
Date: 2023-08-01 08:12:05
Message-ID: CAD21AoA3gS45DFMOyTE-Wm4fu+BYzsYPVcSMYggLxwm40cGHZg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On Thu, Jul 13, 2023 at 5:08 PM Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:
>
> On Sat, Jul 8, 2023 at 11:54 AM John Naylor
> <john(dot)naylor(at)enterprisedb(dot)com> wrote:
> >
> >
> > On Fri, Jul 7, 2023 at 2:19 PM Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:
> > >
> > > On Wed, Jul 5, 2023 at 8:21 PM John Naylor <john(dot)naylor(at)enterprisedb(dot)com> wrote:
> > > > Well, it's going to be a bit of a mess until I can demonstrate it working (and working well) with bitmap heap scan. Fixing that now is just going to create conflicts. I do have a couple small older patches laying around that were quick experiments -- I think at least some of them should give a performance boost in loading speed, but haven't had time to test. Would you like to take a look?
> > >
> > > Yes, I can experiment with these patches in the meantime.
> >
> > Okay, here it is in v36. 0001-6 are same as v35.
> >
> > 0007 removes a wasted extra computation newly introduced by refactoring growing nodes. 0008 just makes 0011 nicer. Not worth testing by themselves, but better to be tidy.
> > 0009 is an experiment to get rid of slow memmoves in node4, addressing a long-standing inefficiency. It looks a bit tricky, but I think it's actually straightforward after drawing out the cases with pen and paper. It works if the fanout is either 4 or 5, so we have some wiggle room. This may give a noticeable boost if the input is reversed or random.
> > 0010 allows RT_EXTEND_DOWN to reduce function calls, so should help with sparse trees.
> > 0011 reduces function calls when growing the smaller nodes. Not sure about this one -- possibly worth it for node4 only?
> >
> > If these help, it'll show up more easily in smaller inputs. Large inputs tend to be more dominated by RAM latency.

cfbot reported some failures[1], and the v36 patch cannot be applied
cleanly to the current HEAD. I've attached updated patches to make
cfbot happy.

Regards,

[1] http://cfbot.cputube.org/highlights/all.html#3687

--
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com

Attachment Content-Type Size
v37-ART.tar.gz application/x-gzip 48.6 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Daniel Gustafsson 2023-08-01 08:13:32 Re: [PATCH] Tracking statements entry timestamp in pg_stat_statements
Previous Message Junwang Zhao 2023-08-01 08:09:32 [PATCH] [zh_CN.po] fix a typo in simplified Chinese translation file