Re: pg_preadv() and pg_pwritev()
От | Thomas Munro |
---|---|
Тема | Re: pg_preadv() and pg_pwritev() |
Дата | |
Msg-id | CA+hUKG+Hf_R_ih1pkBMTWn=STyKMOM2Ks47Y_UqqfU1wRc1VvA@mail.gmail.com обсуждение исходный текст |
Ответ на | RE: pg_preadv() and pg_pwritev() (Jakub Wartak <Jakub.Wartak@tomtom.com>) |
Список | pgsql-hackers |
On Mon, Dec 21, 2020 at 8:25 PM Jakub Wartak <Jakub.Wartak@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 wouldbe doing e.g. 16x fadvise() and then grab 8 pages in one preadv() call ? I'm find unlikely however that preadv giveany 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.)
В списке pgsql-hackers по дате отправления: