3 ms·
Not involved, but giving an educated guess: Imagine a simple search like SELECT * FROM my_table WHERE foo = ? Imagine that the column foo is indexed. With bl
by willvarfar 7y ago
Not involved, but giving an educated guess:
Imagine a simple search like SELECT * FROM my_table WHERE foo = ?
Imagine that the column foo is indexed.
With blocking IO, the we go through the foo index, finding the rows that have the correct value of foo.
The rows we find are on some kind of pages in the storage of the main table. So we now have a list of pages we have to fetch.
With blocking IO, we would fetch a page at a time, process it, then request the next page.
With async IO, we would request the fetching of all pages, as we discover we need them, and then process those pages in the order the IO subsystem can return them to us.
Writes are the same; we have some number of pages we want to write to disk. With blocking IO, we write a page at a time and wait for it to be written. With async you can buffer up the writes, let the OS write them in the order it chooses, and wait for them all to finish.
- mortehu 7y agoNote that writes are asynchronous on Linux too, and only become synchronous when the kernel buffer for writing is full. No special code needed.
- hinkley 7y agoStuff like that is even more confusing because your performance analysis at moderate load tells you absolutely nothing about how the system will behave under high load (people who complain about GC often mention this as one of their grievances) Turns out this causes a lot of issues when working with large diverse teams in particular. If you have a team of 4 you can socialize the idea of avoiding situations like this.