Re: Streaming I/O, vectored I/O (WIP) - Mailing list pgsql-hackers

From Thomas Munro
Subject Re: Streaming I/O, vectored I/O (WIP)
Date
Msg-id CA+hUKG+BqsqOS90Annd6hJoUFwStUrZ=R-5bJFUaoA8ZsLf-cQ@mail.gmail.com
Whole thread Raw
In response to Re: Streaming I/O, vectored I/O (WIP)  (Melanie Plageman <melanieplageman@gmail.com>)
Responses Re: Streaming I/O, vectored I/O (WIP)
List 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 by date:

Previous
From: Nathan Bossart
Date:
Subject: Re: add AVX2 support to simd.h
Next
From: David Rowley
Date:
Subject: Re: incorrect results and different plan with 2 very similar queries