Re: index prefetching
От | Peter Geoghegan |
---|---|
Тема | Re: index prefetching |
Дата | |
Msg-id | CAH2-Wzk-cASQJeLYmPUKRJwoPjqdAy4ZRyXjY7xNsgUFzQPOsg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: index prefetching (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: index prefetching
|
Список | pgsql-hackers |
On Wed, Jul 16, 2025 at 5:41 PM Andres Freund <andres@anarazel.de> wrote: > I don't mean the index tids, but how the read stream is fed block numbers. In > the "complex" patch that's done by index_scan_stream_read_next(). And the > block number it returns is simply > > return ItemPointerGetBlockNumber(tid); > > without the table AM having any way of influencing that. Which means that if > your table AM does not use the block number of the tid 1:1 as the real block > number, the fetched block will be completely bogus. How is that handled when such a table AM uses the existing amgettuple interface? I think that it shouldn't be hard to implement an opt-out of prefetching for such table AMs, so at least you won't fetch random garbage. Right now, the amgetbatch interface is oriented around returning TIDs. Obviously it works that way because that's what heapam expects, and what amgettuple (which I'd like to replace with amgetbatch) does. -- Peter Geoghegan
В списке pgsql-hackers по дате отправления: