Re: index prefetching
От | Tomas Vondra |
---|---|
Тема | Re: index prefetching |
Дата | |
Msg-id | dc68625a-3884-443a-9bb8-4d2c201143a0@vondra.me обсуждение исходный текст |
Ответ на | Re: index prefetching ("Peter Geoghegan" <pg@bowt.ie>) |
Список | pgsql-hackers |
On 8/26/25 03:08, Peter Geoghegan wrote: > On Mon Aug 25, 2025 at 10:18 AM EDT, Tomas Vondra wrote: >> The attached patch is a PoC implementing this. The core idea is that if >> we measure "miss probability" for a chunk of requests, we can use that >> to estimate the distance needed to generate e_i_c IOs. > > I noticed an assertion failure when the tests run. Looks like something about > the patch breaks the read stream from the point of view of VACUUM: > > TRAP: failed Assert("stream->pinned_buffers + stream->pending_read_nblocks <= stream->max_pinned_buffers"), File: "../source/src/backend/storage/aio/read_stream.c",Line: 402, PID: 1238204 > [0x55e71f653d29] read_stream_start_pending_read: /mnt/nvme/postgresql/patch/build_meson_dc/../source/src/backend/storage/aio/read_stream.c:401 Seems the distance adjustment was not quite right, didn't enforce the limit on pinned buffers, and the distance could get too high. The attached version should fix that ... But there's still something wrong. I tried running check-world, and I see 027_stream_regress.pl is getting stuck in join.sql, for the query on line 417. I haven't figured this out yet, but there's a mergejoin. It does reset the stream a lot, so maybe there's something wrong there ... It's strange, though. Why would a different distance make the query stuck? Anyway, Thomas' patch from [1] doesn't seem to have this issue. And maybe it's a better / more elegant approach in general? [1] https://www.postgresql.org/message-id/CA%2BhUKGL2PhFyDoqrHefqasOnaXhSg48t1phs3VM8BAdrZqKZkw%40mail.gmail.com -- Tomas Vondra
Вложения
В списке pgsql-hackers по дате отправления: