4 ms·

FWIW, there is no inherent reason io_uring should be slower. Both implementations look pretty basic to me (checked method_*.c files). Doing thread pool io is mu

FWIW, there is no inherent reason io_uring should be slower. Both implementations look pretty basic to me (checked method_*.c files). Doing thread pool io is much easier than using io_uring properly with all features so it might be possible that it will be better in the future. You can compare worker_pool/io_uring/aio etc. using `fio` to see how different io approaches perform on the same hardware.

pgaddict 1y ago
I believe there are reasons why e.g. io_uring could be inherently slower in some cases, and I tried to point some of those out. With io_uring everything happens in the backend process, and so consumes some of the CPU time that might otherwise be spent executing the query. All the checksum verification, memcpy into shared buffers, etc. happen in the backend. And those things can be quite expensive. With worker this happens in the other processes, spreading the overhead. Of course, on truly I/O-bound workload (actually waiting on the I/O), this may not be a huge difference. For warmed-up cases it may be more significant.
- ozgrakkurt 1y ago
  You can have a io_uring worker per thread and send jobs into a queue for them to pick it up and execute, so it won’t max out on cpu. Each worker would do cooperative async scheduling internally between the tasks so nothing delays other things too much. But this is more difficult than spawning thousands of os threads and running sync workers on them
  - pgaddict 1y ago
    I'm not sure what exactly you mean by "thread" here. Postgres is not thread-based - there are people working on that, but for now it's all processes. Some of these limitations are mostly due to Postgres design, no doubt about that.
    - ozgrakkurt 1y ago
      Ah my mistake. I meant to write something like, you can have a thread per cpu core that is running an io_uring instance like you would have a bunch of workers in a pool in the "worker" implementation. If there are no threads then this would be, you can have a process per cpu core

pgaddict 1y ago

I believe there are reasons why e.g. io_uring could be inherently slower in some cases, and I tried to point some of those out. With io_uring everything happens in the backend process, and so consumes some of the CPU time that might otherwise be spent executing the query. All the checksum verification, memcpy into shared buffers, etc. happen in the backend. And those things can be quite expensive. With worker this happens in the other processes, spreading the overhead. Of course, on truly I/O-bound workload (actually waiting on the I/O), this may not be a huge difference. For warmed-up cases it may be more significant.

ozgrakkurt 1y ago
You can have a io_uring worker per thread and send jobs into a queue for them to pick it up and execute, so it won’t max out on cpu. Each worker would do cooperative async scheduling internally between the tasks so nothing delays other things too much. But this is more difficult than spawning thousands of os threads and running sync workers on them
- pgaddict 1y ago
  I'm not sure what exactly you mean by "thread" here. Postgres is not thread-based - there are people working on that, but for now it's all processes. Some of these limitations are mostly due to Postgres design, no doubt about that.
  - ozgrakkurt 1y ago
    Ah my mistake. I meant to write something like, you can have a thread per cpu core that is running an io_uring instance like you would have a bunch of workers in a pool in the "worker" implementation. If there are no threads then this would be, you can have a process per cpu core