Re: index prefetching - Mailing list pgsql-hackers

From Andres Freund
Subject Re: index prefetching
Date
Msg-id s3bvkigkazntmqbg42fqya3eohikx2jh4prpc342isai55pari@btnpzwtqcf2y
Whole thread Raw
In response to Re: index prefetching  ("Peter Geoghegan" <pg@bowt.ie>)
List pgsql-hackers
Hi,

On 2025-08-14 15:30:16 -0400, Peter Geoghegan wrote:
> On Thu Aug 14, 2025 at 3:15 PM EDT, Peter Geoghegan wrote:
> > On Thu, Aug 14, 2025 at 2:53 PM Andres Freund <andres@anarazel.de> wrote:
> >> I think this is just an indicator of being IO bound.
> >
> > Then why does the exact same pair of runs show "I/O Timings: shared
> > read=194.629" for the sequential table backwards scan (with total
> > execution time 1132.360 ms), versus "I/O Timings: shared read=352.88"
> > (with total execution time 697.681 ms) for the random table backwards
> > scan?
> 
> Is there any particular significance to the invalid op reports I also see in
> the same log files?

>  $ cat sequential.txt | grep invalid | head
>  2025-08-14 14:35:03.278 EDT [2516983][client backend] [[unknown]][0/1:0] DEBUG:  00000: io 0         |op
invalid|targetinvalid|state IDLE            : wait_one io_gen: 2, ref_gen: 1, cycle 1
 
>  2025-08-14 14:35:03.278 EDT [2516983][client backend] [[unknown]][0/1:0] DEBUG:  00000: io 0         |op
invalid|targetinvalid|state IDLE            : wait_one io_gen: 3, ref_gen: 2, cycle 1
 

No - that's likely just that the IO completed and thus the handle was made
reusable (i.e. state IDLE). Note that the generation of IO we're waiting for
(ref_gen) is lower than the IO handle's (io_gen).

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: DSA overflow in hash join
Next
From: Andres Freund
Date:
Subject: Re: index prefetching