Re: Sync scan & regression tests - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Sync scan & regression tests
Date
Msg-id 111619.1695044719@sss.pgh.pa.us
Whole thread Raw
In response to Re: Sync scan & regression tests  (Heikki Linnakangas <hlinnaka@iki.fi>)
List pgsql-hackers
Heikki Linnakangas <hlinnaka@iki.fi> writes:
> On 05/09/2023 06:16, Tom Lane wrote:
>> So chipmunk is getting through the core tests now, but instead it
>> is failing in contrib/pg_visibility [1]:

> I bisected it to this:
> commit 82a4edabd272f70d044faec8cf7fd1eab92d9991 (HEAD)
> Author: Andres Freund <andres@anarazel.de>
> Date:   Mon Aug 14 09:54:03 2023 -0700
>      hio: Take number of prior relation extensions into account

Yeah, I came to the same conclusion after discovering that I could
reproduce it locally with small shared_buffers.

> I think the behavior is fine. The reasons given in the commit message 
> make sense. But it would be nice to silence the test failure. Some 
> alternatives:
> ...
> c) Change the extension logic so that we don't extend so much when the 
> table is small. The efficiency of bulk extension doesn't matter when the 
> table is tiny, so arguably we should rather try to minimize the table 
> size. If you have millions of tiny tables, allocating one extra block on 
> each adds up.

I think your alternative (c) is plenty attractive.  IIUC, the current
change has at one stroke doubled the amount of disk space eaten by
a table that formerly needed two pages.  I don't think we should be
adding more than one page at a time until the table size reaches
perhaps 10 pages.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Daniel Gustafsson
Date:
Subject: Re: Cirrus-ci is lowering free CI cycles - what to do with cfbot, etc?
Next
From: Justin Pryzby
Date:
Subject: pg16: XX000: could not find pathkey item to sort