| From: | Jakub Wartak <Jakub(dot)Wartak(at)tomtom(dot)com> |
|---|---|
| To: | Andrey Borodin <x4mmm(at)yandex-team(dot)ru> |
| Cc: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Kirill Reshke <reshke(at)double(dot)cloud>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | RE: Use fadvise in wal replay |
| Date: | 2022-06-21 10:32:48 |
| Message-ID: | AM8PR07MB82483DABE17210CBC3D872C9F6B39@AM8PR07MB8248.eurprd07.prod.outlook.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> > Maybe the important question is why would be readahead mechanism be
> disabled in the first place via /sys | blockdev ?
>
> Because database should know better than OS which data needs to be
> prefetched and which should not. Big OS readahead affects index scan
> performance.
OK fair point, however the patch here is adding 1 syscall per XLOG_BLCKSZ which is not cheap either. The code is already hot and there is example from the past where syscalls were limiting the performance [1]. Maybe it could be prefetching in larger batches (128kB? 1MB? 16MB?) ?
-J.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Eisentraut | 2022-06-21 10:49:24 | gcc -ftabstop option |
| Previous Message | Andrey Borodin | 2022-06-21 10:24:01 | Re: Use fadvise in wal replay |