[MASSMAIL]Streaming relation data out of order
От | Thomas Munro |
---|---|
Тема | [MASSMAIL]Streaming relation data out of order |
Дата | |
Msg-id | CA+hUKGLPakwZiFUa5fQXpYDpCXvZXQ=P3cWOGACCoobh7U2r3A@mail.gmail.com обсуждение исходный текст |
Ответы |
Re: Streaming relation data out of order
|
Список | pgsql-hackers |
Hi This idea is due to Robert Haas, who complained that he feared that the streaming I/O API already worked like this. It doesn't, but it could! Here is a concept patch to try it out. Normally, read_stream_next_buffer() spits out buffers in the order that the user's callback generated block numbers. This option says that any order would be OK. I had been assuming that this sort of thing would come with real asynchronous I/O: if I/Os complete out of order and the caller explicitly said she doesn't care about block order, we can stream them as the completion events arrive. But even with synchronous I/O, we could stream already-in-cache blocks before ones that require I/O. Letting the caller chew on blocks that are already available maximises the time between fadvise() and preadv() for misses, which minimises the likelihood that the process will have to go to "D" sleep. The patch is pretty trivial: if started with the READ_STREAM_OUT_OF_ORDER flag, "hit" buffers are allowed to jump in front of "miss" buffers in the queue. The attached coding may not be optimal, it's just a proof of concept. ANALYZE benefits from this, for example, with certain kinds of partially cached initial states and fast disks (?). I'm not sure how generally useful it is though. I'm posting it because I wonder if it could be interesting for the streaming bitmap heapscan project, and I wonder how many other things don't care about the order.
Вложения
В списке pgsql-hackers по дате отправления: