Andres Freund

When encountering a postgres instance that is too slow, it's not always easy to identify what makes it slow. Having been asked to analyze "slowness" many times and having worked on postgres for a long time, I will show how I approach answering that question.

PostgreSQL 18 gained support for using asynchronous I/O (AIO) for reads. This talk will discuss the limitations of AIO in PG 18, the workloads in which it can and can't help, and by how much it can help.

PostgreSQL 18 gained support for using asynchronous I/O (AIO) for reads. This talk will discuss the limitations of AIO in PG 18, the workloads in which it can and can't help,.

Most modern computers running PostgreSQL have non-uniform memory access characteristics (NUMA). I.e., accessing some memory is faster than accessing other memory.

For a few years we (Andres Freund, Thomas Munro, Melanie Plageman, David Rowley) have been working towards using asynchronous IO (AIO) and direct IO in Postgres. In this talk I'll describe what using AIO in postgres looks like, what we already have gotten into postgres (e.g.

For a few years we (Andres Freund, Thomas Munro, Melanie Plageman, David Rowley) have been working towards using asynchronous IO (AIO) and direct IO in Postgres. In this talk I'll describe what using AIO in postgres looks like, what we already have gotten into postgres (e.g.

PostgreSQL's IO subsystem—while working well for a large fraction of installations—has a few problems: After an introduction of how PostgreSQL's IO subsystem works, the above problems (and maybe some workarounds), the talk will go over current work to improve this situation. This work includes:

PostgreSQL's IO subsystem - while working well for a large fraction of installations - has a few problems: - hard to predict latency, especially on databases that are significantly larger than the available memory - IO throughput, especially with fast storage subsystems (e.g.