Re: index prefetching

Поиск
Список
Период
Сортировка
От Tomas Vondra
Тема Re: index prefetching
Дата
Msg-id 68b4f0a2-4f41-4ecd-bfb1-6408a70a3579@vondra.me
обсуждение исходный текст
Ответ на Re: index prefetching  (Peter Geoghegan <pg@bowt.ie>)
Список pgsql-hackers

On 11/3/25 00:49, Peter Geoghegan wrote:
> On Sun, Oct 12, 2025 at 2:52 PM Peter Geoghegan <pg@bowt.ie> wrote:
>> Attached in a new revision, mostly just to keep CFBot happy following
>> a recent trivial conflict introduced on master.
> 
> Attached is another revision, also just to keep CFBot happy following
> a conflict introduced on master. Nothing really new here (I've been
> working on batching on the table AM side, but nothing to show on that
> just yet).
> 

Thanks.

> One minor thing to note about this revision: I added a comment to
> selfuncs.c's that notes that there's an unfixed bug there. That code
> more or less copies the approach used by nodeIndexonlyscan.c, but
> neglects to take the same precautions around the read
> stream/prefetching see different pages as all-visible that the view
> seen on the consumer side.
> 
> ISTM that the right fix there is to totally rethink the interface such
> that the read stream is directly owned by the table AM. That way we
> won't have to work around inconsistent ideas around which heap pages
> are all-visible because there'll only be one view of that, in a single
> place. We won't have to do anything special in either selfuncs.c or in
> nodeIndexonlyscan.c.
> 

I think we've already more or less agreed that the read_stream should be
managed by the table AM (rather than by indexam.c), because it's up to
the table AM to interpret the TID.

If that also clarifies the IOS handling, that'd be a bonus. I've not
been very happy with having to check visibility in the stream callback
and passing it to the executor. If this gets "nicer", great.


regards

-- 
Tomas Vondra




В списке pgsql-hackers по дате отправления: