From: Ronan Dunklau <ronan.dunklau@aiven.io>
To: Noah Misch <noah@leadboat.com>
Cc: Michael Paquier <michael@paquier.xyz>
Cc: pgsql-bugs <pgsql-bugs@lists.postgresql.org>
Subject: Re: FSM Corruption (was: Could not read block at end of the relation)
Date: Thu, 21 Mar 2024 14:51:25 +0100
Message-ID: <2493745.irdbgypaU6@aivenlaptop> (raw)
In-Reply-To: <20240316045834.83@rfd.leadboat.com>
References: <VtPLBUerbMM8BSDLQwIMV9Co_38iHS1TXE4V09x2ZVFhPkZMNE8LwgPSIzB8PHkVFXykGx04QNAzZVjJFAnU1w==@protonmail.internalid>
<20240316030339.03.nmisch@google.com>
<20240316045834.83@rfd.leadboat.com>
Le samedi 16 mars 2024, 05:58:34 CET Noah Misch a écrit :
> > Does "that benchmark" refer to "unlogged tables, 4 parallel copies",
> > "logged tables, 4 parallel copies", or something else?
Sorry I was quite busy, and will not find time to run more benchmarks until
next week but I'll get back to it.
It was 4 parallel copies, logged tables. Results for unlogged tables are
similar.
> >
> > > master: 15.05s
> > > patched: 15.24s (+1.25%)
> > >
> > > If I remove the best and worst run for each of those, the difference
> > > falls at +0.7%.
> >
> > To get some additional perspective on the benchmark, how hard would it be
> > to run one or both of the following? Feel free to decline if difficult.
> >
> > - Make GetPageWithFreeSpace() just "return InvalidBlockNumber", then rerun
> > the>
> > benchmark. This should be a lot slower. If not, the bottleneck is
> > somewhere unexpected, and we'd need a different benchmark.
Hum, it doesn't change much so that benchmark does not indeed exercise that
code too aggressively. I was thinking my initial benchmark for the very first
naive version of the patch could work, but I'm afraid it won't show much as
the table size will be cached soon enough.
> >
> > - Get profiles with both master and patched. (lseek or freespace.c
> > functions>
> > rising by 0.1%-1% would fit what we know.)
>
I'll try to run that asap, probably next week unfortunately.
> Forgot one more:
>
> - Your earlier version of the patch, with fewer lseek() but more disuse of
> FSM entries.
Noted.
--
Ronan Dunklau
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-bugs@postgresql.org
Cc: ronan.dunklau@aiven.io, noah@leadboat.com, michael@paquier.xyz, pgsql-bugs@lists.postgresql.org
Subject: Re: FSM Corruption (was: Could not read block at end of the relation)
In-Reply-To: <2493745.irdbgypaU6@aivenlaptop>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox