Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vfFjE-000H14-1o for pgsql-hackers@arkaria.postgresql.org; Mon, 12 Jan 2026 11:04:57 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vfFiE-000JKn-2J for pgsql-hackers@arkaria.postgresql.org; Mon, 12 Jan 2026 11:03:54 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vfFiE-000JKf-0t for pgsql-hackers@lists.postgresql.org; Mon, 12 Jan 2026 11:03:54 +0000 Received: from mail-wm1-x32b.google.com ([2a00:1450:4864:20::32b]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1vfFiC-00018N-0R for pgsql-hackers@lists.postgresql.org; Mon, 12 Jan 2026 11:03:54 +0000 Received: by mail-wm1-x32b.google.com with SMTP id 5b1f17b1804b1-4779adb38d3so42786525e9.2 for ; Mon, 12 Jan 2026 03:03:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1768215831; x=1768820631; darn=lists.postgresql.org; h=content-disposition:mime-version:message-id:subject:to:from:date :from:to:cc:subject:date:message-id:reply-to; bh=ZTrgCNj2IVFwpoRc5qnYgMpW/q4WVn77hah9u9SWWCE=; b=UFFTnzXLTSByJqUvwJ5UmbAoAiDG3YjdbAfjTxSyGdrXvEMDC8BmaFJpA1Fs2noaKl MhTlRpBGbZ1yyqJaDXzWrBsMmNFrxxn8v0Jtt1lGHdjf57H9cd9WFU/3h9SA1ZdRKQzr 8YEilYEgUISiEgMB73NL/gzGiGyjLYT4cHGHPJrvRfGllntuGR1UMp67Tb2e7GC/nEW8 JRE61xZBt6H3uAXQ91A9VpSmV4vVaiNGVJ4veZCI7bwKY6bAucF+DyAl2SlbxjD1f8Dk edDRakvhfZ6acXYssOFVwr3uscsJqTFMvhUjkSSn6Nkz2CVni95PnuAx9TtkcwUX8bMf DUvA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768215831; x=1768820631; h=content-disposition:mime-version:message-id:subject:to:from:date :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=ZTrgCNj2IVFwpoRc5qnYgMpW/q4WVn77hah9u9SWWCE=; b=UcGOQwsyOlHZsTqBruQ6QIG1MAo9+rRo5Ixr7SkgtoiEh5wZu5to9YQg2SZvZGvouJ RGaobW155AKxVC+gDgYoPsbDdiGCp3QTVM05WOrwDSEpEYMMJG2Ug+AYU2zIn1ax1YWP raubqdxF3YuJQZsf/H1Xm5vLcKn/ntq1Krq6gpJpbUYkXuw0qGp3ohkDnLY3KTOINvHG xjipKUKAneRlrTetpPRRQ3f29BBx79nKqjPSoKHTrlbY61a/L3r3qAzwKB/ELiQaaYYb TgY8+Vox2w1In/lzp8/FUgVKmSAobpfmyiy1udqpzK+UPLGtXUH2sRfMvWVrPd/cQL3G diEg== X-Gm-Message-State: AOJu0YxZiyW43Ycr5bO9Mr5bravIiIOAaIyMSl0CZSqJ6FMSNF04fytu 3lIbbKIze6XBqSDFk8eAdPLwR14lsL5iBJGxskUSJMjnKi4y7ikClL/gP78urA== X-Gm-Gg: AY/fxX6tTl25rVq9CCKNkkJRJxiKXI9MMldLHwIL3HpiRj7W6FEXbSuKapS5w1fYmRj AzqU7UDdX7Kurjz8ywZ9omFJS2ESrKFFmXmlsJEhVgLMOuQhi+gihlFCOcf2wAEqbrnRzfH4+2o J06ke5XdiLNI8kAIKHD9kGXEETtvtvzJraqJnhJrICzI4UN7eDbBZ3P5t+p3G58wQt6RFYNjHw8 B3yVsnn16Aw7i0z9nULsQ9If23TG9bQKgrZQ29/ssQJocAeT6P7aNDz8+aVkmHhSdSM6l+7iBPn n4aftSB7EvyUz3+C2XIW8803q1iEoK4lS0DlVNTidzFKY00lyWjyqUzsIVbGBqwGjtW/vYfTYla nQK7P38BSdfiS2RZ+izbQOPZjxjwyi+g0fF/j+ovE1O2J5EIqeko1gsZBJ05SHyyyUhPtL4+6U8 F/+v+S4/Vj0xpGpm3N8VOPI5WD2ti9Gehu/NfXengbWpXyRVTZdSb/8ovA5SWK759BPegu4fK65 ccE5VxFF8Gh/GW2f1kDqljwjcz1jy4f/D0PxinSrrrE2w== X-Google-Smtp-Source: AGHT+IGOoxTYpdDmIoVAuR1xu/ikemIy0Ha3Mq+f9zrfN0ID8RRU/F34WRSDencL44YWFhpjIVQdZw== X-Received: by 2002:a05:600c:1991:b0:477:b48d:ba7a with SMTP id 5b1f17b1804b1-47d84b4119amr181417335e9.32.1768215829669; Mon, 12 Jan 2026 03:03:49 -0800 (PST) Received: from ip-10-97-1-34.eu-west-3.compute.internal (ec2-15-237-197-144.eu-west-3.compute.amazonaws.com. [15.237.197.144]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-47d8636c610sm126358825e9.0.2026.01.12.03.03.48 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 12 Jan 2026 03:03:48 -0800 (PST) Date: Mon, 12 Jan 2026 11:03:47 +0000 From: Bertrand Drouvot To: pgsql-hackers@lists.postgresql.org Subject: Flush some statistics within running transactions Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="tjEWjIIwfNIHQLgt" Content-Disposition: inline List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --tjEWjIIwfNIHQLgt Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi hackers, Long running transactions can accumulate significant statistics (WAL, IO, ...) that remain unflushed until the transaction ends. This delays visibility of resource usage in monitoring views like pg_stat_io and pg_stat_wal. This patch series introduce the ability to $SUBJECT (suggested in [1]) to: - improve monitoring of long running transactions - avoid missing places where we should flush statistics (like the one fixed in 039549d70f6) The patch series is made of 3 sub-patches: 0001: Add pgstat_report_anytime_stat() for periodic stats flushing It introduces pgstat_report_anytime_stat(), which flushes non transactional statistics even inside active transactions. A new timeout handler fires every second to call this function, ensuring timely stats visibility without waiting for transaction completion. Implementation details: - Add PgStat_FlushBehavior enum to classify stats kinds: * FLUSH_ANYTIME: Stats that can always be flushed (WAL, IO, ...) * FLUSH_AT_TXN_BOUNDARY: Stats requiring transaction boundaries - Modify pgstat_flush_pending_entries() and pgstat_flush_fixed_stats() to accept a boolean anytime_only parameter: * When false: flushes all stats (existing behavior) * When true: flushes only FLUSH_ANYTIME stats and skips FLUSH_AT_TXN_BOUNDARY stats - Register ANYTIME_STATS_UPDATE_TIMEOUT that fires every 1 second, calling pgstat_report_anytime_stat(false) Remarks: - The force parameter in pgstat_report_anytime_stat() is currently unused (always called with force=false) but reserved for future use cases requiring immediate flushing. The 1 second flush interval is currently hardcoded but we could imagine increase it or make it configurable. I ran some benchmarks and did not notice any noticeable performance regression even with a large number of pending entries. 0002: Remove useless calls to flush some stats Now that some stats can be flushed outside of transaction boundaries, remove useless calls to flush some stats. Those calls were in place because before 0001 stats were flushed only at transaction boundaries. Remarks: - it reverts 039549d70f6 (it just keeps its tests) - it can't be done for checkpointer and bgworker for example because they don't have a flush callback to call - it can't be done for auxiliary process (walsummarizer for example) because they currently do not register the new timeout handler - we may want to improve the current behavior to "fix" the 2 above 0003: Add FLUSH_MIXED support and implement it for RELATION stats This patch extends the non transactional stats infrastructure to support statistics kinds with mixed transaction behavior: some fields are transactional (e.g., tuple inserts/updates/deletes) while others are non transactional (e.g., sequential scans blocks read, ...). It introduces FLUSH_MIXED as a third flush behavior type, alongside FLUSH_ANYTIME and FLUSH_AT_TXN_BOUNDARY. For FLUSH_MIXED kinds, a new flush_anytime_cb callback enables partial flushing of only the non transactional fields during running transactions. Some tests are also added. Implementation details: - Add FLUSH_MIXED to PgStat_FlushBehavior enum - Add flush_anytime_cb to PgStat_KindInfo for partial flushing callback - Update pgstat_flush_pending_entries() to call flush_anytime_cb for FLUSH_MIXED entries when in anytime_only mode - Keep FLUSH_MIXED entries in the pending list after partial flush, as transactional fields still need to be flushed at transaction boundary RELATION stats are making use of FLUSH_MIXED: - Change RELATION from TXN_ALL to FLUSH_MIXED - Implement pgstat_relation_flush_anytime_cb() to flush only read related stats: numscans, tuples_returned, tuples_fetched, blocks_fetched, blocks_hit - Clear these fields after flushing to prevent double counting when pgstat_relation_flush_cb() runs at transaction commit - Transactional stats (tuples_inserted, tuples_updated, tuples_deleted, live_tuples, dead_tuples) remain pending until transaction boundary Remark: We could also imagine adding a new flush_anytime_static_cb() callback for future FLUSH_MIXED fixed amount stats. [1]: https://postgr.es/m/erpzwxoptqhuptdrtehqydzjapvroumkhh7lc6poclbhe7jk7l%40l3yfsq5q4pw7 Regards, -- Bertrand Drouvot PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com --tjEWjIIwfNIHQLgt Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="v1-0001-Add-pgstat_report_anytime_stat-for-periodic-stats.patch"