Re: FSM Corruption (was: Could not read block at end of the relation)

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