Re: BTScanOpaqueData size slows down tests
От | Andres Freund |
---|---|
Тема | Re: BTScanOpaqueData size slows down tests |
Дата | |
Msg-id | 647aitqk7ssezrl4e6mk6lyz3xuzflbgqimmrfsvjinvuxi6sw@7p6emyg3fqrj обсуждение исходный текст |
Ответ на | Re: BTScanOpaqueData size slows down tests (Peter Geoghegan <pg@bowt.ie>) |
Ответы |
Re: BTScanOpaqueData size slows down tests
|
Список | pgsql-hackers |
Hi, On 2025-04-02 12:01:57 -0400, Peter Geoghegan wrote: > On Wed, Apr 2, 2025 at 11:57 AM Andres Freund <andres@anarazel.de> wrote: > > I'd assume it's extremely rare for there to be this many items on a page. I'd > > guess that something like storing having BTScanPosData->items point to an > > in-line 4-16 BTScanPosItem items_inline[N] and dynamically allocate a > > full-length BTScanPosItem[MaxTIDsPerBTreePage] just in the cases it's needed. > > There can still only be MaxIndexTuplesPerPage items on the page (407 > if memory serves) -- deduplication didn't change that. Sure. > It isn't at all rare for the scan to have to return about 1350 TIDs > from a page, though. Any low cardinality index will tend to have > almost that many TIDs to return on any page that only stores > duplicates. And scan will necessarily have to return all of the TIDs > from such a page, if it has to return any. I'm not sure what you're arguing for/against here? Obviously we need to handle that case. I doubt that the overhead of once-per-scan allocation of a MaxTIDsPerBTreePage * sizeof(BTScanPosItem) array once per scan matters when that many tuples are returned. Greetings, Andres Freund
В списке pgsql-hackers по дате отправления: