Re: index prefetching
От | Andres Freund |
---|---|
Тема | Re: index prefetching |
Дата | |
Msg-id | s3bvkigkazntmqbg42fqya3eohikx2jh4prpc342isai55pari@btnpzwtqcf2y обсуждение исходный текст |
Ответ на | Re: index prefetching ("Peter Geoghegan" <pg@bowt.ie>) |
Список | 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 по дате отправления: