On Thu, Apr 10, 2025 at 7:35 AM Andres Freund wrote:
> 1) Increase distance by * 2 + read_size on a miss
>
>This would help us to increase with distance = 1, where * 2 only increases
>distance by 1, just as -1 obviously reduces it by 1.
>
>It'd also somewhat address the over-weighing o
Hi,
On 2025-04-09 19:17:00 +1200, Thomas Munro wrote:
> One weird issue, not just with reordering, is that read_stream.c's
> distance cools off too easily with some simple test patterns. Start
> at 1, double on miss, subtract one on hit, repeat, and you can be
> trapped alternating between 1 and
Here is a more fleshed out version of this concept patch, now that we
have lots of streams wired up to try it with. Bitmap Heap Scan seemed
to be a good candidate.
postgres=# create table t (a int unique, b int unique);
CREATE TABLE
postgres=# insert into t select generate_series(1, 10),
gene
On Tue, Apr 9, 2024 at 12:19 AM Thomas Munro wrote:
> This idea is due to Robert Haas, who complained that he feared that
> the streaming I/O API already worked like this. It doesn't, but it
> could! Here is a concept patch to try it out.
Oh, no, it's all my fault!
My favorite part of this pat
Hi
This idea is due to Robert Haas, who complained that he feared that
the streaming I/O API already worked like this. It doesn't, but it
could! Here is a concept patch to try it out.
Normally, read_stream_next_buffer() spits out buffers in the order
that the user's callback generated block num
