On 5/9/25 17:55, Peter Geoghegan wrote: > On Fri, May 9, 2025 at 10:57 AM Tomas Vondra <to...@vondra.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
