Re: Asynchronous and "direct" IO support for PostgreSQL.
Andres Freund <andres@anarazel.de>
From: Andres Freund <andres@anarazel.de>
To: Alexey Lesovsky <alexey.lesovsky@dataegret.com>
Cc: pgsql-hackers@postgresql.org, Thomas Munro <thomas.munro@gmail.com>
Date: 2021-02-24T21:03:16Z
Lists: pgsql-hackers
Hi, On 2021-02-24 21:15:14 +0500, Alexey Lesovsky wrote: > pg_stat_aios. > In general, this stat is a set of text values, and at the same time it looks > GAUGE-like (similar to pg_stat_activity or pg_locks), and is only relevant > for the moment when the user is looking at it. I think it would be better to > rename this view to pg_stat_progress_aios. And keep pg_stat_aios for other > AIO stats with global COUNTERs (like stuff in pg_stat_user_tables or > pg_stat_statements, or system-wide /proc/stat, /proc/diskstats). Right - arguably it really shouldn't even have _stat_ in the name... I don't particularly like the idea of adding _progress_ as that seems it'd lead to confusing it with pg_stat_progress_vacuum etc - and it's quite a different beast. > pg_stat_aio_backends. > This stat is based on COUNTERs, which is great, but the issue here is that > its lifespan is limited by the lifespan of the backend processes - once the > backend exits the stat will no longer be available - which could be > inappropriate in workloads with short-lived backends. There's a todo somewhere to roll over the per-connection stats into a global stats piece on disconnect. In addition I was thinking of adding a view that sums up the value of "already disconnected backends" and the currently connected ones. Would that mostly address your concerns? > I think there might be few existing examples in the current code that could > be repurposed to implement the suggestions above (such as > pg_stat_user_tables, pg_stat_database, etc). With this in mind, I think > having these changes incorporated shouldn’t take significant effort > considering the benefit it will bring to the final user. Yea - I kind of was planning to go somewhere roughly in the direction you suggest, but took a few shortcuts due to the size of the project. Having the views made it a lot easier to debug / develop, but supporting longer lived stuff wasn't yet crucial. But I agree, we really should have it... Greetings, Andres Freund
Commits
-
aio: Add README.md explaining higher level design
- fdd146a8ef2b 18.0 landed
-
bufmgr: Use AIO in StartReadBuffers()
- 12ce89fd0708 18.0 landed
-
bufmgr: Implement AIO read support
- 047cba7fa0f8 18.0 landed
-
aio: Implement support for reads in smgr/md/fd
- 50cb7505b301 18.0 landed
-
aio: Add io_method=io_uring
- c325a7633fcb 18.0 landed
-
aio: Add io_method=worker
- 247ce06b883d 18.0 landed
-
aio: Infrastructure for io_method=worker
- 55b454d0e140 18.0 landed
-
aio: Add core asynchronous I/O infrastructure
- da7226993fd4 18.0 landed