On Mon, Dec 21, 2020 at 8:25 PM Jakub Wartak <jakub.war...@tomtom.com> wrote: > > > I'm drawing a blank on trivial candidate uses for preadv(), without > > > infrastructure from later patches. > > > > Can't immediately think of something either. > > This might be not that trivial , but maybe acquire_sample_rows() from > analyze.c ? > > Please note however there's patch > https://www.postgresql.org/message-id/20201109180644.GJ16415%40tamriel.snowman.net > ( https://commitfest.postgresql.org/30/2799/ ) for adding fadvise, but maybe > those two could be even combined so you would be doing e.g. 16x fadvise() and > then grab 8 pages in one preadv() call ? I'm find unlikely however that > preadv give any additional performance benefit there after having fadvise, > but clearly a potential place to test.
Oh, interesting, that looks like another test case to study with the AIO patch set, but I don't think it's worth trying to do a simpler/half-baked version in the meantime. (Since that ANALYZE patch uses PrefetchBuffer() it should automatically benefit: the posix_fadvise() calls will be replaced with consolidated preadv() calls in a worker process or native AIO equivalent so that system calls are mostly gone from the initiating process, and by the time you try to access the buffer it'll hopefully see that it's finished without any further system calls. Refinements are possible though, like making use of recent_buffer to avoid double-lookup, and tuning/optimisation for how often IOs should be consolidated and submitted.)
