{"id":10439,"date":"2025-12-15T10:53:23","date_gmt":"2025-12-15T09:53:23","guid":{"rendered":"https:\/\/www.credativ.de\/?p=10439"},"modified":"2025-12-15T10:53:23","modified_gmt":"2025-12-15T09:53:23","slug":"postgresql-18-asynchronous-disk-i-o-deep-dive-into-implementation","status":"publish","type":"post","link":"https:\/\/www.credativ.de\/en\/blog\/postgresql-en\/postgresql-18-asynchronous-disk-i-o-deep-dive-into-implementation\/","title":{"rendered":"PostgreSQL 18 Asynchronous Disk I\/O &#8211; Deep Dive Into Implementation"},"content":{"rendered":"<div>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"alignright size-medium wp-image-10512\" src=\"https:\/\/www.credativ.de\/wp-content\/uploads\/2025\/12\/Database-Async-IO-1-300x300.jpg\" alt=\"AI generated image symbolizing an asynchronous running database\" width=\"300\" height=\"300\" srcset=\"https:\/\/www.credativ.de\/wp-content\/uploads\/2025\/12\/Database-Async-IO-1-300x300.jpg 300w, https:\/\/www.credativ.de\/wp-content\/uploads\/2025\/12\/Database-Async-IO-1-1024x1024.jpg 1024w, https:\/\/www.credativ.de\/wp-content\/uploads\/2025\/12\/Database-Async-IO-1-150x150.jpg 150w, https:\/\/www.credativ.de\/wp-content\/uploads\/2025\/12\/Database-Async-IO-1-768x768.jpg 768w, https:\/\/www.credativ.de\/wp-content\/uploads\/2025\/12\/Database-Async-IO-1-1536x1536.jpg 1536w, https:\/\/www.credativ.de\/wp-content\/uploads\/2025\/12\/Database-Async-IO-1-600x600.jpg 600w, https:\/\/www.credativ.de\/wp-content\/uploads\/2025\/12\/Database-Async-IO-1-180x180.jpg 180w, https:\/\/www.credativ.de\/wp-content\/uploads\/2025\/12\/Database-Async-IO-1.jpg 1772w\" sizes=\"auto, (max-width: 300px) 100vw, 300px\" \/>PostgreSQL 17 introduced streaming I\/O \u2013 grouping multiple page reads into a single system call and using smarter posix_fadvise() hints. That alone gave up to ~30% faster sequential scans in some workloads, but it was still strictly synchronous: each backend process would issue a read and then sit there waiting for the kernel to return data before proceeding. Before PG17, PostgreSQL typically read one 8kB page at a time.<\/p>\n<\/div>\n<div><a href=\"https:\/\/www.credativ.de\/en\/portfolio\/support\/postgresql-competence-center\/\">PostgreSQL 18<\/a> takes the next logical step: a full asynchronous I\/O (AIO) subsystem that can keep multiple reads in flight while backends keep doing useful work. Reads become overlapped instead of only serialized. The AIO subsystem is deliberately targeted at operations that know their future block numbers ahead of time and can issue multiple reads in advance:<\/div>\n<ul>\n<li>Heap sequential scans, like plain SELECT and COPY operations that stream lots of data<\/li>\n<li>VACUUM on big tables and indexes<\/li>\n<li>ANALYZE sampling<\/li>\n<li>Bitmap heap scans<\/li>\n<\/ul>\n<p><a href=\"https:\/\/www.credativ.de\/en\/blog\/postgresql-en\/postgresql-and-undelete\/\">Autovacuum<\/a> benefits from this change too, since its workers share the same VACUUM\/ANALYZE code paths. Other operations still remain synchronous for now:<\/p>\n<ul>\n<li>B\u2011tree index scans \/ index\u2011only scans<\/li>\n<li>Recovery &amp; replication<\/li>\n<li>All write operations INSERT, UPDATE, DELETE, WAL writes<\/li>\n<li>Small OLTP lookups that touch a single heap page<\/li>\n<\/ul>\n<div>\n<p>Future work is expected to widen coverage, especially index\u2011only scans and some write\u2011path optimizations.<\/p>\n<h4>Significant improvements for cloud volumes<\/h4>\n<p><a href=\"https:\/\/pganalyze.com\/blog\/postgres-18-async-io\">Community benchmarks<\/a> show that PostgreSQL 18 AIO significantly improves cold cache data reads in cloud setups with network\u2011attached storage where latency is high. <a href=\"https:\/\/docs.aws.amazon.com\/ebs\/latest\/userguide\/provisioned-iops.html\">AWS documentation<\/a> states that average latency of Block Express volumes is &#8220;under 500 microseconds for 16 KiB I\/O size&#8221;, when latency of General Purpose volumes can exceed 800 microseconds. Some articles suggest that under high load each physical block read from disk can cost around 1ms, while page processing in PostgreSQL is much cheaper. By combining many pages into one read, all these pages together now cost around 1ms. And by performing multiple reading requests at the same time in parallel, we effectively pay that 1ms latency just once per the whole batch.<\/p>\n<h4>Asynchronous I\/O methods<\/h4>\n<p>The new subsystem can run in one of three modes, configured via <em><strong>io_method<\/strong><\/em> parameter with possible values &#8220;<em>worker<\/em>&#8221; (default), &#8220;<em>io_uring<\/em>&#8220;, and &#8220;<em>sync<\/em>&#8220;. We will cover how each works and then show how to monitor asynchronous I\/O in our environment.<\/p>\n<\/div>\n<h5>io_method = sync<\/h5>\n<div>\n<p>This mode effectively turns AIO off. Reads are executed through the same AIO API but synchronously, using regular preadv or pwritev methods on the backend process that issued the I\/O. This method does not use any extra shared memory and is intended mainly for regression testing or if we suspect AIO is misbehaving. It is also used internally as fall back to the synchronous I\/O for operations which cannot use asynchronous I\/O. PostgreSQL core functions issue an error, if some extension would try to force asynchronous I\/O through AIO API when global io_method is set to &#8220;sync&#8221;. Available benchmarks show that this PostgreSQL 18 mode performs similarly to PostgreSQL 17\u2019s streaming I\/O.<\/p>\n<\/div>\n<h5>io_method = io_uring (Linux only)<\/h5>\n<div>On modern Linux (kernel version 5.1 or higher), PostgreSQL can talk directly to the kernel\u2019s io_uring interface. Usage requires PostgreSQL to be built with liburing support &#8211; we can check it inside PostgreSQL using select from pg_config() function:<\/div>\n<div><\/div>\n<blockquote>\n<pre>SELECT pg_config FROM pg_config() where pg_config::text ilike \u2019%liburing%\u2019;<\/pre>\n<\/blockquote>\n<div>PostgreSQL asynchronous I\/O operations (both io_uring and worker) use shared memory structures for issuing the requests and receiving info about its completion or failure. This way PostgreSQL AIO code can manage batching and concurrency without direct dependency on specific AIO method. PostgreSQL code maintains one separate io_uring instance for each backend, including auxiliary processes. But rings are created in the postmaster, so they can use shared memory and there is no contention or blocking between backends.<\/div>\n<div><\/div>\n<div>Processing scenario is very simple:<\/div>\n<ol>\n<li>Backends write requests via API into a submission ring in shared memory<\/li>\n<li>The kernel performs I\/O asynchronously and writes results into a completion ring<\/li>\n<li>Completion ring content is consumed by the backend with fewer context switches<\/li>\n<\/ol>\n<div>\n<p>Execution still happens in the same process, like with the &#8220;<em>sync<\/em>&#8221; method, but it uses kernel worker threads for parallel processing. This typically shines on very fast NVMe SSDs.<\/p>\n<p>However, io_uring Linux feature also has had a rough security history. It bypasses traditional syscall audit paths and therefore has been involved in a large share of Linux kernel exploits. Google reported that 60% of Linux kernel vulnerabilities in 2022 involved io_uring and some security tools were unable to uncover these types of attacks. Therefore some container environments disable io_uring entirely.<\/p>\n<\/div>\n<h5>io_method = worker<\/h5>\n<div>\n<p>This is the cross\u2011platform, \u201csafe\u201d implementation and the default in PostgreSQL 18. Mechanism is very similar to existing parallel query processing. The main difference is that background I\/O workers are long\u2011lived independent processes created at server start, not short\u2011lived processes spawned per query.<\/p>\n<\/div>\n<div>Typical flow:<\/div>\n<ol>\n<li>At server start, the postmaster creates a pool of I\/O worker processes. Number is controlled by <em><strong>io_workers<\/strong><\/em> parameter with a default of <em>3<\/em>. However, benchmarks suggest this number should be higher on many\u2011core machines, typically between \u00bc and \u00bd of available CPU threads. Best value depends on workload and storage latency.<\/li>\n<li>Backends submit read requests into a shared memory submission queue. This submission queue is generally a ring buffer that multiple backends can write into concurrently. It contains only metadata about the request &#8211; handle indices, not full request record. There is only one submission queue for the entire cluster, not per database or per backend. The actual details of the request are stored in separate memory structure.<\/li>\n<li>Request is checked if it must be executed synchronously or can be handled asynchronously. Synchronous execution can also be chosen if the submission queue is full. This avoids problems with shared memory usage under extreme load. In case of synchronous execution, code uses path for &#8220;sync&#8221; method described above.<\/li>\n<li>Request submission in shared memory wakes up one I\/O worker, which pops request and executes traditional blocking read() \/ pread() calls. If queue is still not empty, woken worker can wake up 2 additional workers to process it in parallel. Note in code mentions that this can be in the future extended to configurable N workers. This limit helps to avoid so called &#8220;thundering herd problem&#8221;, when single submitter would wake up too many workers causing havoc and locks for other backends.<\/li>\n<li>One limitation for asynchronous I\/O is the fact, that workers cannot simply reuse file descriptors opened by backends, they must reopen files in their own context. If this is not possible for some types of operations, synchronous I\/O path is used for that specific request.<\/li>\n<li>When workers finish a request without an error, they write data blocks into share buffers, put result into a completion queue and signal the backend.<\/li>\n<li>From the perspective of the backend, I\/O becomes \u201casynchronous\u201d, because the &#8220;waiting&#8221; happens in worker processes, not in the query process itself.<\/li>\n<\/ol>\n<div>Advantages of this approach:<\/div>\n<ul>\n<li>Works on all supported OSes<\/li>\n<li>Simple error handling: if a worker crashes, requests are marked as failed, worker exits and a new worker is spawned by postmaster<\/li>\n<li>Avoids the security concerns around Linux io_uring interface<\/li>\n<li>The downside is extra context switches and possible shared\u2011memory queue contention, but for many workloads the ability to overlap reads easily pays for that<\/li>\n<li>This method improves performance even in the case when all blocks are just copied from local Linux memory cache, because it is now done in parallel<\/li>\n<\/ul>\n<h4>Tuning the New I\/O Parameters<\/h4>\n<div>\n<p>PostgreSQL 18 adds or updates several parameters related to disk I\/O. We already covered <em><strong>io_method<\/strong><\/em> and <em><strong>io_workers<\/strong><\/em>; let\u2019s look at the others. Another new parameters are <em><strong>io_combine_limit<\/strong><\/em> and <em><strong>io_max_combine_limit<\/strong><\/em>. They control how many data pages PostgreSQL groups into a single AIO request. Larger requests typically yield better throughput, but can also increase latency and memory usage.\u00a0Values without units are interpreted in 8kB data blocks. With units (kB, MB), they directly represent size &#8211; however, should be multiples of 8kB.<\/p>\n<p>Parameter <em><strong>io_max_combine_limit<\/strong><\/em> is a hard server\u2011start cap, <em><strong>io_combine_limit<\/strong><\/em> is the user\u2011tunable value that can be changed at runtime but cannot exceed the max. Default values of both is 128kB (16 data pages). But documentation recommends setting up to 1MB on Unix (128 data pages) and 128kB on Windows (16 data pages &#8211; due to limitations in internal Widows buffers). We can experiment with higher values, but based on HW and OS limits AIO benefits plateau after some chunk size; pushing this too high doesn\u2019t help and can even increase latency.<\/p>\n<p>PostgreSQL 18 introduces also <em><strong>io_max_concurrency<\/strong><\/em> setting, which controls max number of IOs that one process can execute simultaneously. Default setting <em>-1<\/em> means value will be selected automatically based on other settings, but it cannot exceed 64.<\/p>\n<p>Other related parameter is <em><strong>effective_io_concurrency<\/strong><\/em> &#8211; number of concurrent I\/O operations that can be executed simultaneously on storage. Range of values is from 1 to 1000, value 0 disables asynchronous I\/O requests. Default value is now 16, some community articles suggest to go up to 200 on modern SSDs. Best setting depends on specific hardware and OS, however, some articles also warn that too high value may significantly increase I\/O latency for all queries.<\/p>\n<\/div>\n<h4>How to Monitor Asynchronous I\/O<\/h4>\n<h5>pg_stat_activity<\/h5>\n<div>For <em>io_method = worker<\/em> background I\/O workers are visible in <em><strong>pg_stat_activity<\/strong><\/em> as <em>backend_type = &#8216;io worker&#8217;<\/em>. They show <em>wait_event_type<\/em> \/ <em>wait_event<\/em> values Activity \/ IoWorkerMain when they are idle, or typically IO \/ DataFileRead when they\u2019re busy doing work.<\/div>\n<div><\/div>\n<blockquote>\n<pre>SELECT pid, backend_start, wait_event_type, wait_event, backend_type\r\nFROM pg_stat_activity\r\nWHERE backend_type = 'io worker';\r\n\r\n\r\n  pid |        backend_start          | wait_event_type |  wait_event  | backend_type\r\n------+-------------------------------+-----------------+--------------+--------------\r\n  \u00a034 | 2025-12-09 11:44:23.852461+00 | Activity        | IoWorkerMain | io worker\r\n   35 | 2025-12-09 11:44:23.852832+00 | Activity        | IoWorkerMain | io worker\r\n  \u00a036 | 2025-12-09 11:44:23.853119+00 | IO              | DataFileRead | io worker\r\n   37 | 2025-12-09 11:44:23.8534+00   | IO              | DataFileRead | io worker<\/pre>\n<\/blockquote>\n<div>We can combine <em><strong>pg_stat_io<\/strong><\/em> with <em><strong>pg_stat_activity<\/strong><\/em> to see which backends are issuing AIO requests, which queries they\u2019re running and what their current AIO state is:<\/div>\n<div><\/div>\n<blockquote>\n<pre>SELECT a.pid, a.usename, a.application_name, a.backend_type, a.state, a.query,\r\nai.operation, ai.state AS aio_state, ai.length AS aio_bytes, ai.target_desc\r\nFROM pg_aios ai\r\nJOIN pg_stat_activity a ON a.pid = ai.pid\r\nORDER BY a.backend_type, a.pid, ai.io_id;\r\n\r\n\r\n-[ RECORD 1 ]----+------------------------------------------------------------------------\r\n             pid | 58\r\n         usename | postgres\r\napplication_name | psql\r\n    backend_type | client backend\r\n           state | active\r\n           query | explain analyze SELECT ........\r\n       operation | readv\r\n       aio_state | SUBMITTED\r\n       aio_bytes | 704512\r\n     target_desc | blocks 539820..539905 in file \"pg_tblspc\/16647\/PG_18_202506291\/5\/16716\"\r\n-[ RECORD 2 ]----+------------------------------------------------------------------------\r\n             pid | 159\r\n         usename | postgres\r\napplication_name | psql\r\n    backend_type | parallel worker\r\n           state | active\r\n          \u00a0query | explain analyze SELECT ........\r\n       operation | readv\r\n       aio_state | SUBMITTED\r\n       aio_bytes | 704512\r\n     target_desc | blocks 536326..536411 in file \"pg_tblspc\/16647\/PG_18_202506291\/5\/16716\"\r\n\r\n<\/pre>\n<\/blockquote>\n<h5>pg_aios: Current AIO handles<\/h5>\n<div>PostgreSQL 18 introduces several new observability features to help us to monitor asynchronous I\/O in action. New system view <em><strong>pg_aios<\/strong><\/em> is listing currently in\u2011use asynchronous I\/O handles \u2013 essentially \u201cI\/O requests that are being prepared, executed, or finishing\u201d.<\/div>\n<div>Key columns are for each handle:<\/div>\n<ul>\n<li>pid: backend issuing the I\/O<\/li>\n<li>io_id, io_generation: identify a handle across reuse<\/li>\n<li>state: HANDED_OUT, DEFINED, STAGED, SUBMITTED, COMPLETED_IO, COMPLETED_SHARED, COMPLETED_LOCAL<\/li>\n<li>operation: invalid, readv (vectored read) or writev (vectored write)<\/li>\n<li>off, length: offset and size of I\/O operation<\/li>\n<li>target, target_desc: what we\u2019re reading\/writing (typically relations)<\/li>\n<li>result: UNKNOWN, OK, PARTIAL, WARNING, ERROR<\/li>\n<\/ul>\n<div>We can generate some simple stats of all I\/Os currently in flight, grouped by state and result:<\/div>\n<div><\/div>\n<blockquote>\n<pre>-- Summary of current AIO handles by state and result\r\nSELECT state, result, count(*) AS cnt, pg_size_pretty(sum(length)) AS total_size\r\nFROM pg_aios GROUP BY state, result ORDER BY state, result;\r\n\r\n       state      |  result | cnt | total_size\r\n------------------+---------+-----+------------\r\n COMPLETED_SHARED | OK      |   1 | 688 kB\r\n SUBMITTED        | UNKNOWN |   6 | 728 kB\r\n\r\n-- In-flight async I\/O handles\r\nSELECT COUNT(*) AS aio_handles, SUM(length) AS aio_bytes FROM pg_aios;\r\n\r\n aio_handles | aio_bytes\r\n-------------+-----------\r\n           7 |     57344\r\n\r\n-- Sessions currently waiting on I\/O\r\nSELECT COUNT(*) AS sessions_waiting_on_io FROM pg_stat_activity WHERE wait_event_type = 'IO';\r\n\r\n sessions_waiting_on_io\r\n------------------------\r\n                      9<\/pre>\n<\/blockquote>\n<div>Or we can use it to see details about current AIO requests:<\/div>\n<div><\/div>\n<blockquote>\n<pre>SELECT pid, state, operation, pg_size_pretty(length) AS io_size, target_desc, result\r\nFROM pg_aios ORDER BY pid, io_id;\r\n\r\n pid |   state   | operation |   io_size  |                             target_desc                                 | result\r\n-----+-----------+-----------+------------+-------------------------------------------------------------------------+---------\r\n  51 | SUBMITTED | readv     | 688 kB     | blocks 670470..670555 in file \"pg_tblspc\/16647\/PG_18_202506291\/5\/16716\" | UNKNOWN\r\n  63 | SUBMITTED | readv     | 8192 bytes | block 1347556 in file \"pg_tblspc\/16647\/PG_18_202506291\/5\/16719\"         | UNKNOWN\r\n  65 | SUBMITTED | readv     | 688 kB     | blocks 671236..671321 in file \"pg_tblspc\/16647\/PG_18_202506291\/5\/16716\" | UNKNOWN\r\n  66 | SUBMITTED | readv     | 8192 bytes | block 1344674 in file \"pg_tblspc\/16647\/PG_18_202506291\/5\/16719\"         | UNKNOWN\r\n  67 | SUBMITTED | readv     | 8192 bytes | block 1337819 in file \"pg_tblspc\/16647\/PG_18_202506291\/5\/16719\"         | UNKNOWN\r\n  68 | SUBMITTED | readv     | 688 kB     | blocks 672002..672087 in file \"pg_tblspc\/16647\/PG_18_202506291\/5\/16716\" | UNKNOWN\r\n  69 | SUBMITTED | readv     | 688 kB     | blocks 673964..674049 in file \"pg_tblspc\/16647\/PG_18_202506291\/5\/16716\" | UNKNOWN<\/pre>\n<\/blockquote>\n<h5>pg_stat_io: Cumulative I\/O stats<\/h5>\n<div>Catalog view <em><strong>pg_stat_io<\/strong><\/em> was introduced in PostgreSQL 16, but PostgreSQL 18 extends it with byte counters (read_bytes, write_bytes, extend_bytes) and better coverage of WAL and bulk I\/O contexts.\u00a0However, timing columns are only populated if we enable the timing parameters &#8211; <em><strong>track_io_timing<\/strong><\/em> &#8211; default is off.<\/div>\n<div><\/div>\n<div>A handy per\u2011client view of relation I\/O:<\/div>\n<div><\/div>\n<blockquote>\n<pre>SELECT backend_type, context, sum(reads) AS reads, \r\npg_size_pretty(sum(read_bytes)) AS read_bytes, \r\nround(sum(read_time)::numeric, 2) AS read_ms, sum(writes) AS writes, \r\npg_size_pretty(sum(write_bytes)) AS write_bytes,\r\nround(sum(write_time)::numeric, 2) AS write_ms, sum(extends) AS extends,\r\npg_size_pretty(sum(extend_bytes)) AS extend_bytes\r\nFROM pg_stat_io\r\nWHERE object = 'relation' AND backend_type IN ('client backend')\r\nGROUP BY backend_type, context\r\nORDER BY backend_type, context;\r\n\r\n   backend_type |  context  |  reads  | read_bytes |  read_ms  | writes | write_bytes | write_ms | extends | extend_bytes\r\n----------------+-----------+---------+------------+-----------+--------+-------------+----------+---------+--------------\r\n client backend | bulkread  |   13833 | 9062 MB    | 124773.28 |      0 | 0 bytes     |     0.00 |         |\r\n client backend | bulkwrite |       0 | 0 bytes    |      0.00 |      0 | 0 bytes     |     0.00 |       0 | 0 bytes\r\n client backend | init      |       0 | 0 bytes    |      0.00 |      0 | 0 bytes     |     0.00 |       0 | 0 bytes\r\n client backend | normal    | 2265214 | 17 GB      | 553940.57 |      0 | 0 bytes     |     0.00 |       0 | 0 bytes\r\n client backend | vacuum    |       0 | 0 bytes    |      0.00 |      0 | 0 bytes     |     0.00 |       0 | 0 bytes\r\n\r\n\r\n-- Top tables by heap blocks read and cache hit ratio\r\nSELECT relid::regclass AS table_name, heap_blks_read, heap_blks_hit,\r\nROUND( CASE WHEN heap_blks_read + heap_blks_hit = 0 THEN 0\r\nELSE heap_blks_hit::numeric \/ (heap_blks_read + heap_blks_hit) * 100 END, 2) AS cache_hit_pct\r\nFROM pg_statio_user_tables\r\nORDER BY heap_blks_read DESC LIMIT 20;\r\n\r\n      table_name      | heap_blks_read | heap_blks_hit | cache_hit_pct\r\n----------------------+----------------+---------------+---------------\r\n table1               |       18551282 |       3676632 |         16.54\r\n table2               |        1513673 |     102222970 |         98.54\r\n table3               |          19713 |       1034435 |         98.13\r\n...\r\n\r\n\r\n-- Top indexes by index blocks read and cache hit ratio\r\nSELECT relid::regclass AS table_name, indexrelid::regclass AS index_name,\r\nidx_blks_read, idx_blks_hit \r\nFROM pg_statio_user_indexes\r\nORDER BY idx_blks_read DESC LIMIT 20;\r\n\r\n table_name |    index_name   | idx_blks_read | idx_blks_hit\r\n------------+-----------------+---------------+--------------\r\n table1     | idx_table1_date |        209289 |          141\r\n table2     | table2_pkey     |         37221 |      1223747\r\n table3     | table3_pkey     |          9825 |      3143947\r\n...<\/pre>\n<\/blockquote>\n<div>For establishing a baseline before\/after a test run, we can reset stats (as superuser):<\/div>\n<blockquote>\n<pre>SELECT pg_stat_reset_shared('io');<\/pre>\n<\/blockquote>\n<p>Then run our workload and query pg_stat_io again to see how many bytes were read\/written and how much time was spent waiting on I\/O.<\/p>\n<h4>Conclusion<\/h4>\n<div>PostgreSQL 18\u2019s new asynchronous I\/O subsystem is a significant step forward in improving I\/O performance for large scans and maintenance operations. By overlapping reads and allowing multiple requests to be in flight, it can better utilize modern storage systems and reduce query times for data-intensive workloads. With the new observability features in pg_aios and pg_stat_io, DBAs and developers can monitor AIO activity and tune parameters to optimize performance for their specific workloads. As PostgreSQL continues to evolve, we can expect further enhancements to the AIO subsystem and broader coverage of operations that can benefit from asynchronous I\/O.<\/div>\n<p>PostgreSQL is a registered trademark oftThe\u00a0<a href=\"https:\/\/www.postgres.ca\/\">PostgreSQL Community Association of Canada<\/a>.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>PostgreSQL 17 introduced streaming I\/O \u2013 grouping multiple page reads into a single system call and using smarter posix_fadvise() hints. That alone gave up to ~30% faster sequential scans in some workloads, but it was still strictly synchronous: each backend process would issue a read and then sit there waiting for the kernel to return [&hellip;]<\/p>\n","protected":false},"author":82,"featured_media":10515,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1708],"tags":[1707,1887,2098,1801],"class_list":["post-10439","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-postgresql-en","tag-planetpostgres","tag-planetpostgresql","tag-postgresql-18","tag-postgresql-en"],"acf":[],"yoast_head":"<!-- This site is optimized with the Yoast SEO Premium plugin v27.6 (Yoast SEO v27.6) - https:\/\/yoast.com\/product\/yoast-seo-premium-wordpress\/ -->\n<title>PostgreSQL 18 Asynchronous Disk I\/O - Deep Dive Into Implementation - credativ\u00ae<\/title>\n<meta name=\"description\" content=\"PostgreSQL 18 Asynchronous Disk I\/O improves efficiency with a new AIO system that processes multiple read operations simultaneously.\" \/>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/www.credativ.de\/en\/blog\/postgresql-en\/postgresql-18-asynchronous-disk-i-o-deep-dive-into-implementation\/\" \/>\n<meta property=\"og:locale\" content=\"en_US\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"PostgreSQL 18 Asynchronous Disk I\/O - Deep Dive Into Implementation\" \/>\n<meta property=\"og:description\" content=\"PostgreSQL 18 Asynchronous Disk I\/O improves efficiency with a new AIO system that processes multiple read operations simultaneously.\" \/>\n<meta property=\"og:url\" content=\"https:\/\/www.credativ.de\/en\/blog\/postgresql-en\/postgresql-18-asynchronous-disk-i-o-deep-dive-into-implementation\/\" \/>\n<meta property=\"og:site_name\" content=\"credativ\u00ae\" \/>\n<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/credativDE\/\" \/>\n<meta property=\"article:published_time\" content=\"2025-12-15T09:53:23+00:00\" \/>\n<meta property=\"og:image\" content=\"https:\/\/www.credativ.de\/wp-content\/uploads\/2025\/12\/Database-Async-IO-1-banner.jpg\" \/>\n\t<meta property=\"og:image:width\" content=\"1920\" \/>\n\t<meta property=\"og:image:height\" content=\"1080\" \/>\n\t<meta property=\"og:image:type\" content=\"image\/jpeg\" \/>\n<meta name=\"author\" content=\"Josef Machytka\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:description\" content=\"PostgreSQL 18 Asynchronous Disk I\/O improves efficiency with a new AIO system that processes multiple read operations simultaneously.\" \/>\n<meta name=\"twitter:creator\" content=\"@credativde\" \/>\n<meta name=\"twitter:site\" content=\"@credativde\" \/>\n<meta name=\"twitter:label1\" content=\"Written by\" \/>\n\t<meta name=\"twitter:data1\" content=\"Josef Machytka\" \/>\n\t<meta name=\"twitter:label2\" content=\"Est. reading time\" \/>\n\t<meta name=\"twitter:data2\" content=\"11 minutes\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\\\/\\\/schema.org\",\"@graph\":[{\"@type\":\"Article\",\"@id\":\"https:\\\/\\\/www.credativ.de\\\/en\\\/blog\\\/postgresql-en\\\/postgresql-18-asynchronous-disk-i-o-deep-dive-into-implementation\\\/#article\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/www.credativ.de\\\/en\\\/blog\\\/postgresql-en\\\/postgresql-18-asynchronous-disk-i-o-deep-dive-into-implementation\\\/\"},\"author\":{\"name\":\"Josef Machytka\",\"@id\":\"https:\\\/\\\/www.credativ.de\\\/en\\\/#\\\/schema\\\/person\\\/b5f03833b09ed0acd1c8d3307d05bd1a\"},\"headline\":\"PostgreSQL 18 Asynchronous Disk I\\\/O &#8211; Deep Dive Into Implementation\",\"datePublished\":\"2025-12-15T09:53:23+00:00\",\"mainEntityOfPage\":{\"@id\":\"https:\\\/\\\/www.credativ.de\\\/en\\\/blog\\\/postgresql-en\\\/postgresql-18-asynchronous-disk-i-o-deep-dive-into-implementation\\\/\"},\"wordCount\":2004,\"commentCount\":1,\"publisher\":{\"@id\":\"https:\\\/\\\/www.credativ.de\\\/en\\\/#organization\"},\"image\":{\"@id\":\"https:\\\/\\\/www.credativ.de\\\/en\\\/blog\\\/postgresql-en\\\/postgresql-18-asynchronous-disk-i-o-deep-dive-into-implementation\\\/#primaryimage\"},\"thumbnailUrl\":\"https:\\\/\\\/www.credativ.de\\\/wp-content\\\/uploads\\\/2025\\\/12\\\/Database-Async-IO-1-banner.jpg\",\"keywords\":[\"planetpostgres\",\"planetpostgresql\",\"postgresql 18\",\"PostgreSQL\u00ae\"],\"articleSection\":[\"PostgreSQL\u00ae\"],\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"CommentAction\",\"name\":\"Comment\",\"target\":[\"https:\\\/\\\/www.credativ.de\\\/en\\\/blog\\\/postgresql-en\\\/postgresql-18-asynchronous-disk-i-o-deep-dive-into-implementation\\\/#respond\"]}],\"copyrightYear\":\"2025\",\"copyrightHolder\":{\"@id\":\"https:\\\/\\\/www.credativ.de\\\/#organization\"}},{\"@type\":\"WebPage\",\"@id\":\"https:\\\/\\\/www.credativ.de\\\/en\\\/blog\\\/postgresql-en\\\/postgresql-18-asynchronous-disk-i-o-deep-dive-into-implementation\\\/\",\"url\":\"https:\\\/\\\/www.credativ.de\\\/en\\\/blog\\\/postgresql-en\\\/postgresql-18-asynchronous-disk-i-o-deep-dive-into-implementation\\\/\",\"name\":\"PostgreSQL 18 Asynchronous Disk I\\\/O - Deep Dive Into Implementation - credativ\u00ae\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/www.credativ.de\\\/en\\\/#website\"},\"primaryImageOfPage\":{\"@id\":\"https:\\\/\\\/www.credativ.de\\\/en\\\/blog\\\/postgresql-en\\\/postgresql-18-asynchronous-disk-i-o-deep-dive-into-implementation\\\/#primaryimage\"},\"image\":{\"@id\":\"https:\\\/\\\/www.credativ.de\\\/en\\\/blog\\\/postgresql-en\\\/postgresql-18-asynchronous-disk-i-o-deep-dive-into-implementation\\\/#primaryimage\"},\"thumbnailUrl\":\"https:\\\/\\\/www.credativ.de\\\/wp-content\\\/uploads\\\/2025\\\/12\\\/Database-Async-IO-1-banner.jpg\",\"datePublished\":\"2025-12-15T09:53:23+00:00\",\"description\":\"PostgreSQL 18 Asynchronous Disk I\\\/O improves efficiency with a new AIO system that processes multiple read operations simultaneously.\",\"breadcrumb\":{\"@id\":\"https:\\\/\\\/www.credativ.de\\\/en\\\/blog\\\/postgresql-en\\\/postgresql-18-asynchronous-disk-i-o-deep-dive-into-implementation\\\/#breadcrumb\"},\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\\\/\\\/www.credativ.de\\\/en\\\/blog\\\/postgresql-en\\\/postgresql-18-asynchronous-disk-i-o-deep-dive-into-implementation\\\/\"]}]},{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\\\/\\\/www.credativ.de\\\/en\\\/blog\\\/postgresql-en\\\/postgresql-18-asynchronous-disk-i-o-deep-dive-into-implementation\\\/#primaryimage\",\"url\":\"https:\\\/\\\/www.credativ.de\\\/wp-content\\\/uploads\\\/2025\\\/12\\\/Database-Async-IO-1-banner.jpg\",\"contentUrl\":\"https:\\\/\\\/www.credativ.de\\\/wp-content\\\/uploads\\\/2025\\\/12\\\/Database-Async-IO-1-banner.jpg\",\"width\":1920,\"height\":1080},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\\\/\\\/www.credativ.de\\\/en\\\/blog\\\/postgresql-en\\\/postgresql-18-asynchronous-disk-i-o-deep-dive-into-implementation\\\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Home\",\"item\":\"https:\\\/\\\/www.credativ.de\\\/en\\\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"PostgreSQL 18 Asynchronous Disk I\\\/O &#8211; Deep Dive Into Implementation\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\\\/\\\/www.credativ.de\\\/en\\\/#website\",\"url\":\"https:\\\/\\\/www.credativ.de\\\/en\\\/\",\"name\":\"credativ GmbH\",\"description\":\"\",\"publisher\":{\"@id\":\"https:\\\/\\\/www.credativ.de\\\/en\\\/#organization\"},\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\\\/\\\/www.credativ.de\\\/en\\\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"en-US\"},{\"@type\":[\"Organization\",\"Place\"],\"@id\":\"https:\\\/\\\/www.credativ.de\\\/en\\\/#organization\",\"name\":\"credativ\u00ae\",\"url\":\"https:\\\/\\\/www.credativ.de\\\/en\\\/\",\"logo\":{\"@id\":\"https:\\\/\\\/www.credativ.de\\\/en\\\/blog\\\/postgresql-en\\\/postgresql-18-asynchronous-disk-i-o-deep-dive-into-implementation\\\/#local-main-organization-logo\"},\"image\":{\"@id\":\"https:\\\/\\\/www.credativ.de\\\/en\\\/blog\\\/postgresql-en\\\/postgresql-18-asynchronous-disk-i-o-deep-dive-into-implementation\\\/#local-main-organization-logo\"},\"sameAs\":[\"https:\\\/\\\/www.facebook.com\\\/credativDE\\\/\",\"https:\\\/\\\/x.com\\\/credativde\",\"https:\\\/\\\/mastodon.social\\\/@credativde\",\"https:\\\/\\\/www.linkedin.com\\\/company\\\/credativ-gmbh\",\"https:\\\/\\\/www.instagram.com\\\/credativ\\\/\"],\"description\":\"Die credativ GmbH ist ein f\u00fchrendes, auf Open Source Software spezialisiertes IT-Dienstleistungs- und Beratungsunternehmen. Wir bieten umfassende und professionelle Services, von Beratung und Infrastruktur-Betrieb \u00fcber 24\\\/7 Support bis hin zu individuellen L\u00f6sungen und Schulungen. Unser Fokus liegt auf dem ganzheitlichen Management von gesch\u00e4ftskritischen Open-Source-Systemen, darunter Betriebssysteme (z.B. Linux), Datenbanken (z.B. PostgreSQL), Konfigurationsmanagement (z.B. Ansible, Puppet) und Virtualisierung. Als engagierter Teil der Open-Source-Community unterst\u00fctzen wir unsere Kunden dabei, die Vorteile freier Software sicher, stabil und effizient in ihrer IT-Umgebung zu nutzen.\",\"legalName\":\"credativ GmbH\",\"foundingDate\":\"2025-03-01\",\"duns\":\"316387060\",\"numberOfEmployees\":{\"@type\":\"QuantitativeValue\",\"minValue\":\"11\",\"maxValue\":\"50\"},\"address\":{\"@id\":\"https:\\\/\\\/www.credativ.de\\\/en\\\/blog\\\/postgresql-en\\\/postgresql-18-asynchronous-disk-i-o-deep-dive-into-implementation\\\/#local-main-place-address\"},\"geo\":{\"@type\":\"GeoCoordinates\",\"latitude\":\"51.1732374\",\"longitude\":\"6.392010099999999\"},\"telephone\":[\"+4921619174200\",\"08002733284\"],\"contactPoint\":{\"@type\":\"ContactPoint\",\"telephone\":\"08002733284\",\"email\":\"vertrieb@credativ.de\"},\"openingHoursSpecification\":[{\"@type\":\"OpeningHoursSpecification\",\"dayOfWeek\":[\"Monday\",\"Tuesday\",\"Wednesday\",\"Thursday\",\"Friday\"],\"opens\":\"09:00\",\"closes\":\"17:00\"},{\"@type\":\"OpeningHoursSpecification\",\"dayOfWeek\":[\"Saturday\",\"Sunday\"],\"opens\":\"00:00\",\"closes\":\"00:00\"}],\"email\":\"info@credativ.de\",\"areaServed\":\"D-A-CH\",\"vatID\":\"DE452151696\"},{\"@type\":\"Person\",\"@id\":\"https:\\\/\\\/www.credativ.de\\\/en\\\/#\\\/schema\\\/person\\\/b5f03833b09ed0acd1c8d3307d05bd1a\",\"name\":\"Josef Machytka\"},{\"@type\":\"PostalAddress\",\"@id\":\"https:\\\/\\\/www.credativ.de\\\/en\\\/blog\\\/postgresql-en\\\/postgresql-18-asynchronous-disk-i-o-deep-dive-into-implementation\\\/#local-main-place-address\",\"streetAddress\":\"Hennes-Weisweiler-Allee 23\",\"addressLocality\":\"M\u00f6nchengladbach\",\"postalCode\":\"41179\",\"addressRegion\":\"Deutschland\",\"addressCountry\":\"DE\"},{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\\\/\\\/www.credativ.de\\\/en\\\/blog\\\/postgresql-en\\\/postgresql-18-asynchronous-disk-i-o-deep-dive-into-implementation\\\/#local-main-organization-logo\",\"url\":\"https:\\\/\\\/www.credativ.de\\\/wp-content\\\/uploads\\\/2025\\\/04\\\/credativ-logo-right.svg\",\"contentUrl\":\"https:\\\/\\\/www.credativ.de\\\/wp-content\\\/uploads\\\/2025\\\/04\\\/credativ-logo-right.svg\",\"caption\":\"credativ\u00ae\"}]}<\/script>\n<meta name=\"geo.placename\" content=\"M\u00f6nchengladbach\" \/>\n<meta name=\"geo.position\" content=\"51.1732374;6.392010099999999\" \/>\n<meta name=\"geo.region\" content=\"Germany\" \/>\n<!-- \/ Yoast SEO Premium plugin. -->","yoast_head_json":{"title":"PostgreSQL 18 Asynchronous Disk I\/O - Deep Dive Into Implementation - credativ\u00ae","description":"PostgreSQL 18 Asynchronous Disk I\/O improves efficiency with a new AIO system that processes multiple read operations simultaneously.","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/www.credativ.de\/en\/blog\/postgresql-en\/postgresql-18-asynchronous-disk-i-o-deep-dive-into-implementation\/","og_locale":"en_US","og_type":"article","og_title":"PostgreSQL 18 Asynchronous Disk I\/O - Deep Dive Into Implementation","og_description":"PostgreSQL 18 Asynchronous Disk I\/O improves efficiency with a new AIO system that processes multiple read operations simultaneously.","og_url":"https:\/\/www.credativ.de\/en\/blog\/postgresql-en\/postgresql-18-asynchronous-disk-i-o-deep-dive-into-implementation\/","og_site_name":"credativ\u00ae","article_publisher":"https:\/\/www.facebook.com\/credativDE\/","article_published_time":"2025-12-15T09:53:23+00:00","og_image":[{"width":1920,"height":1080,"url":"https:\/\/www.credativ.de\/wp-content\/uploads\/2025\/12\/Database-Async-IO-1-banner.jpg","type":"image\/jpeg"}],"author":"Josef Machytka","twitter_card":"summary_large_image","twitter_description":"PostgreSQL 18 Asynchronous Disk I\/O improves efficiency with a new AIO system that processes multiple read operations simultaneously.","twitter_creator":"@credativde","twitter_site":"@credativde","twitter_misc":{"Written by":"Josef Machytka","Est. reading time":"11 minutes"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"Article","@id":"https:\/\/www.credativ.de\/en\/blog\/postgresql-en\/postgresql-18-asynchronous-disk-i-o-deep-dive-into-implementation\/#article","isPartOf":{"@id":"https:\/\/www.credativ.de\/en\/blog\/postgresql-en\/postgresql-18-asynchronous-disk-i-o-deep-dive-into-implementation\/"},"author":{"name":"Josef Machytka","@id":"https:\/\/www.credativ.de\/en\/#\/schema\/person\/b5f03833b09ed0acd1c8d3307d05bd1a"},"headline":"PostgreSQL 18 Asynchronous Disk I\/O &#8211; Deep Dive Into Implementation","datePublished":"2025-12-15T09:53:23+00:00","mainEntityOfPage":{"@id":"https:\/\/www.credativ.de\/en\/blog\/postgresql-en\/postgresql-18-asynchronous-disk-i-o-deep-dive-into-implementation\/"},"wordCount":2004,"commentCount":1,"publisher":{"@id":"https:\/\/www.credativ.de\/en\/#organization"},"image":{"@id":"https:\/\/www.credativ.de\/en\/blog\/postgresql-en\/postgresql-18-asynchronous-disk-i-o-deep-dive-into-implementation\/#primaryimage"},"thumbnailUrl":"https:\/\/www.credativ.de\/wp-content\/uploads\/2025\/12\/Database-Async-IO-1-banner.jpg","keywords":["planetpostgres","planetpostgresql","postgresql 18","PostgreSQL\u00ae"],"articleSection":["PostgreSQL\u00ae"],"inLanguage":"en-US","potentialAction":[{"@type":"CommentAction","name":"Comment","target":["https:\/\/www.credativ.de\/en\/blog\/postgresql-en\/postgresql-18-asynchronous-disk-i-o-deep-dive-into-implementation\/#respond"]}],"copyrightYear":"2025","copyrightHolder":{"@id":"https:\/\/www.credativ.de\/#organization"}},{"@type":"WebPage","@id":"https:\/\/www.credativ.de\/en\/blog\/postgresql-en\/postgresql-18-asynchronous-disk-i-o-deep-dive-into-implementation\/","url":"https:\/\/www.credativ.de\/en\/blog\/postgresql-en\/postgresql-18-asynchronous-disk-i-o-deep-dive-into-implementation\/","name":"PostgreSQL 18 Asynchronous Disk I\/O - Deep Dive Into Implementation - credativ\u00ae","isPartOf":{"@id":"https:\/\/www.credativ.de\/en\/#website"},"primaryImageOfPage":{"@id":"https:\/\/www.credativ.de\/en\/blog\/postgresql-en\/postgresql-18-asynchronous-disk-i-o-deep-dive-into-implementation\/#primaryimage"},"image":{"@id":"https:\/\/www.credativ.de\/en\/blog\/postgresql-en\/postgresql-18-asynchronous-disk-i-o-deep-dive-into-implementation\/#primaryimage"},"thumbnailUrl":"https:\/\/www.credativ.de\/wp-content\/uploads\/2025\/12\/Database-Async-IO-1-banner.jpg","datePublished":"2025-12-15T09:53:23+00:00","description":"PostgreSQL 18 Asynchronous Disk I\/O improves efficiency with a new AIO system that processes multiple read operations simultaneously.","breadcrumb":{"@id":"https:\/\/www.credativ.de\/en\/blog\/postgresql-en\/postgresql-18-asynchronous-disk-i-o-deep-dive-into-implementation\/#breadcrumb"},"inLanguage":"en-US","potentialAction":[{"@type":"ReadAction","target":["https:\/\/www.credativ.de\/en\/blog\/postgresql-en\/postgresql-18-asynchronous-disk-i-o-deep-dive-into-implementation\/"]}]},{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/www.credativ.de\/en\/blog\/postgresql-en\/postgresql-18-asynchronous-disk-i-o-deep-dive-into-implementation\/#primaryimage","url":"https:\/\/www.credativ.de\/wp-content\/uploads\/2025\/12\/Database-Async-IO-1-banner.jpg","contentUrl":"https:\/\/www.credativ.de\/wp-content\/uploads\/2025\/12\/Database-Async-IO-1-banner.jpg","width":1920,"height":1080},{"@type":"BreadcrumbList","@id":"https:\/\/www.credativ.de\/en\/blog\/postgresql-en\/postgresql-18-asynchronous-disk-i-o-deep-dive-into-implementation\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https:\/\/www.credativ.de\/en\/"},{"@type":"ListItem","position":2,"name":"PostgreSQL 18 Asynchronous Disk I\/O &#8211; Deep Dive Into Implementation"}]},{"@type":"WebSite","@id":"https:\/\/www.credativ.de\/en\/#website","url":"https:\/\/www.credativ.de\/en\/","name":"credativ GmbH","description":"","publisher":{"@id":"https:\/\/www.credativ.de\/en\/#organization"},"potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/www.credativ.de\/en\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"en-US"},{"@type":["Organization","Place"],"@id":"https:\/\/www.credativ.de\/en\/#organization","name":"credativ\u00ae","url":"https:\/\/www.credativ.de\/en\/","logo":{"@id":"https:\/\/www.credativ.de\/en\/blog\/postgresql-en\/postgresql-18-asynchronous-disk-i-o-deep-dive-into-implementation\/#local-main-organization-logo"},"image":{"@id":"https:\/\/www.credativ.de\/en\/blog\/postgresql-en\/postgresql-18-asynchronous-disk-i-o-deep-dive-into-implementation\/#local-main-organization-logo"},"sameAs":["https:\/\/www.facebook.com\/credativDE\/","https:\/\/x.com\/credativde","https:\/\/mastodon.social\/@credativde","https:\/\/www.linkedin.com\/company\/credativ-gmbh","https:\/\/www.instagram.com\/credativ\/"],"description":"Die credativ GmbH ist ein f\u00fchrendes, auf Open Source Software spezialisiertes IT-Dienstleistungs- und Beratungsunternehmen. Wir bieten umfassende und professionelle Services, von Beratung und Infrastruktur-Betrieb \u00fcber 24\/7 Support bis hin zu individuellen L\u00f6sungen und Schulungen. Unser Fokus liegt auf dem ganzheitlichen Management von gesch\u00e4ftskritischen Open-Source-Systemen, darunter Betriebssysteme (z.B. Linux), Datenbanken (z.B. PostgreSQL), Konfigurationsmanagement (z.B. Ansible, Puppet) und Virtualisierung. Als engagierter Teil der Open-Source-Community unterst\u00fctzen wir unsere Kunden dabei, die Vorteile freier Software sicher, stabil und effizient in ihrer IT-Umgebung zu nutzen.","legalName":"credativ GmbH","foundingDate":"2025-03-01","duns":"316387060","numberOfEmployees":{"@type":"QuantitativeValue","minValue":"11","maxValue":"50"},"address":{"@id":"https:\/\/www.credativ.de\/en\/blog\/postgresql-en\/postgresql-18-asynchronous-disk-i-o-deep-dive-into-implementation\/#local-main-place-address"},"geo":{"@type":"GeoCoordinates","latitude":"51.1732374","longitude":"6.392010099999999"},"telephone":["+4921619174200","08002733284"],"contactPoint":{"@type":"ContactPoint","telephone":"08002733284","email":"vertrieb@credativ.de"},"openingHoursSpecification":[{"@type":"OpeningHoursSpecification","dayOfWeek":["Monday","Tuesday","Wednesday","Thursday","Friday"],"opens":"09:00","closes":"17:00"},{"@type":"OpeningHoursSpecification","dayOfWeek":["Saturday","Sunday"],"opens":"00:00","closes":"00:00"}],"email":"info@credativ.de","areaServed":"D-A-CH","vatID":"DE452151696"},{"@type":"Person","@id":"https:\/\/www.credativ.de\/en\/#\/schema\/person\/b5f03833b09ed0acd1c8d3307d05bd1a","name":"Josef Machytka"},{"@type":"PostalAddress","@id":"https:\/\/www.credativ.de\/en\/blog\/postgresql-en\/postgresql-18-asynchronous-disk-i-o-deep-dive-into-implementation\/#local-main-place-address","streetAddress":"Hennes-Weisweiler-Allee 23","addressLocality":"M\u00f6nchengladbach","postalCode":"41179","addressRegion":"Deutschland","addressCountry":"DE"},{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/www.credativ.de\/en\/blog\/postgresql-en\/postgresql-18-asynchronous-disk-i-o-deep-dive-into-implementation\/#local-main-organization-logo","url":"https:\/\/www.credativ.de\/wp-content\/uploads\/2025\/04\/credativ-logo-right.svg","contentUrl":"https:\/\/www.credativ.de\/wp-content\/uploads\/2025\/04\/credativ-logo-right.svg","caption":"credativ\u00ae"}]},"geo.placename":"M\u00f6nchengladbach","geo.position":{"lat":"51.1732374","long":"6.392010099999999"},"geo.region":"Germany"},"_links":{"self":[{"href":"https:\/\/www.credativ.de\/en\/wp-json\/wp\/v2\/posts\/10439","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.credativ.de\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.credativ.de\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.credativ.de\/en\/wp-json\/wp\/v2\/users\/82"}],"replies":[{"embeddable":true,"href":"https:\/\/www.credativ.de\/en\/wp-json\/wp\/v2\/comments?post=10439"}],"version-history":[{"count":42,"href":"https:\/\/www.credativ.de\/en\/wp-json\/wp\/v2\/posts\/10439\/revisions"}],"predecessor-version":[{"id":10516,"href":"https:\/\/www.credativ.de\/en\/wp-json\/wp\/v2\/posts\/10439\/revisions\/10516"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.credativ.de\/en\/wp-json\/wp\/v2\/media\/10515"}],"wp:attachment":[{"href":"https:\/\/www.credativ.de\/en\/wp-json\/wp\/v2\/media?parent=10439"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.credativ.de\/en\/wp-json\/wp\/v2\/categories?post=10439"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.credativ.de\/en\/wp-json\/wp\/v2\/tags?post=10439"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}