Hi, On 2023-01-19 22:19:10 +0100, Tomas Vondra wrote: > So I'm a bit unsure about this patch. I doesn't seem like it can perform > better than read-ahead (although perhaps it does, on a different storage > system).
I really don't see the point of the patch as-is. It's not going to help OSs without useful readahead, because those don't have posix_fadvise either. And hardcoded readahead distance isn't useful - on e.g. cloud storage 128kB won't be long enough to overcome network latency. I could see a *tad* more point in using posix_fadvise(fd, 0, 0, POSIX_FADV_SEQUENTIAL) when opening WAL files, as that'll increase the kernel readahead window over what's configured. > With disabled read-ahead it helps (at least a bit), although I'm not > really convinced there are good reasons to run without read-ahead. The > reason for doing that was described like this: Agreed. Postgres currently totally crashes and burns without OS readhead. Buffered IO without readahead makes no sense. So I just don't see the point of this patch. > > Because database should know better than OS which data needs to be > > prefetched and which should not. Big OS readahead affects index scan > > performance. I don't disagree fundamentally. But that doesn't make this patch a useful starting point. Greetings, Andres Freund
