With the unexplained but apparently somewhat systematic regression patterns on certain tests and settings, I wonder if they might be due to read_stream.c trying to form larger reads, making it a bit lazier. It tries to see what the next block will be before issuing the fadvise. I think that means that with small I/O concurrency settings, there might be contrived access patterns where it loses, and needs effective_io_concurrency to be set one notch higher to keep up, or something like that. One way to test that idea would be to run the tests with io_combine_limit = 1 (meaning 1 block). It issues advise eagerly when io_combine_limit is reached, so I suppose it should be exactly as eager as master. The only difference then should be that it automatically suppresses sequential fadvise calls.
- Re: BitmapHeapScan streaming ... Robert Haas
- Re: BitmapHeapScan streaming read user and prelim ... Tomas Vondra
- Re: BitmapHeapScan streaming read user and prelim refac... Heikki Linnakangas
- Re: BitmapHeapScan streaming read user and prelim ... Heikki Linnakangas
- Re: BitmapHeapScan streaming read user and pre... Melanie Plageman
- Re: BitmapHeapScan streaming read user and... Tomas Vondra
- Re: BitmapHeapScan streaming read user... Tomas Vondra
- Re: BitmapHeapScan streaming read... Melanie Plageman
- Re: BitmapHeapScan streaming ... Tomas Vondra
- Re: BitmapHeapScan streaming ... Melanie Plageman
- Re: BitmapHeapScan streaming ... Thomas Munro
- Re: BitmapHeapScan streaming ... Tomas Vondra
- Re: BitmapHeapScan streaming ... Thomas Munro
- Re: BitmapHeapScan streaming ... Tomas Vondra
- Re: BitmapHeapScan streaming ... Thomas Munro
- Re: BitmapHeapScan streaming ... Tomas Vondra
- Re: BitmapHeapScan streaming ... Thomas Munro
- Re: BitmapHeapScan streaming ... Thomas Munro
- Re: BitmapHeapScan streaming ... Thomas Munro
- Re: BitmapHeapScan streaming ... Thomas Munro
- Re: BitmapHeapScan streaming ... Tomas Vondra