Re: Adding skip scan (including MDAM style range skip scan) to nbtree

On 5/9/25 17:55, Peter Geoghegan wrote:
> On Fri, May 9, 2025 at 10:57 AM Tomas Vondra <tomas(at)vondra(dot)me> wrote:
>> I see the regression even with variants that actually match some rows.
>> For example if I do this:
>
>> so that the query matches 100 rows, I get the same behavior.
>
> That's really weird, since the index scans will no longer be cheap.
> And yet whatever the overhead is still seems to be plainly visible. I
> would expect whatever the underlying problem is to be completely
> drowned out once the index scan had to do real work.
>

Not sure if it matters, but this uses index-only scans, and the pages
are all-visible, so maybe it's not much more expensive.

> I wonder if it could be due to the fact that I added a new support
> function, support function #6/skip support? That would have increased
> the size of things like RelationData.rd_support and
> RelationData.rd_supportinfo.
>
> Note that "sizeof(FmgrInfo)" is 48 bytes. Prior to skip scan,
> RelationData.rd_supportinfo would have required 48*5=240 bytes. After
> skip scan, it would have required 48*6=288 bytes. Maybe 256 bytes is
> some kind of critical threshold, someplace?
>

Not sure, I did multiple tests with different queries, and it'd be a bit
strange if this was the only one affected. Not impossible.

The theory about crossing the 256B threshold is interesting. I've been
thinking about ALLOC_CHUNK_LIMIT = 8KB, which is what's making the
BTScanOpaque expensive. But there's also ALLOC_CHUNK_FRACTION, which is
1/4. So maybe there's a context with maxBlockSize=1kB? But I think most
places use the size macros, and ALLOCSET_SMALL_MAXSIZE is 8KB.

regards

--
Tomas Vondra