Re: Streaming I/O, vectored I/O (WIP)
От | Thomas Munro |
---|---|
Тема | Re: Streaming I/O, vectored I/O (WIP) |
Дата | |
Msg-id | CA+hUKG+BqsqOS90Annd6hJoUFwStUrZ=R-5bJFUaoA8ZsLf-cQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Streaming I/O, vectored I/O (WIP) (Melanie Plageman <melanieplageman@gmail.com>) |
Ответы |
Re: Streaming I/O, vectored I/O (WIP)
|
Список | pgsql-hackers |
On Thu, Mar 28, 2024 at 9:43 AM Melanie Plageman <melanieplageman@gmail.com> wrote: > For sequential scan, I added a little reset function to the streaming > read API (read_stream_reset()) that just releases all the buffers. > Previously, it set finished to true before releasing the buffers (to > indicate it was done) and then set it back to false after. Now, I'll > set distance to 0 before releasing the buffers and !0 after. I could > just restore whatever value distance had before I set it to 0. Or I > could set it to 1. But, thinking about it, are we sure we want to ramp > up in the same way on rescans? Maybe we want to use some information > from the previous scan to determine what to set distance to? Maybe I'm > overcomplicating it... I think 1 is good, as a rescan is even more likely to find the pages in cache, and if that turns out to be wrong it'll very soon adjust.
В списке pgsql-hackers по дате отправления: