[PROPOSAL] Platform-native resource usage stats for Windows

From: Bryan Green <dbryan(dot)green(at)gmail(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Subject: [PROPOSAL] Platform-native resource usage stats for Windows
Date: 2025-10-19 15:58:49
Message-ID: e9c0fcae-e99c-45a8-90ae-ea5dd2b553c3@gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


Hello,

I'd like to propose an enhancement to how PostgreSQL reports resource
usage statistics on Windows, building on a 2017 discussion initiated by
Justin Pryzby [1].

I've been spending some time reviewing windows specific code in the
postgresql codebase. I've notice several "opportunities" for
enhancements and cleanup-- especially if we are only supporting Windows
10+. One of the areas I noticed was getrusage().

The current Windows getrusage() shim in src/port/getrusage.c only
reports CPU times. Everything else is zero. Windows has better
performance APIs than Unix getrusage() in several areas - we're just not
using them.

Back in 2017, Justin Pryzby proposed exposing ru_maxrss [1], and Robert
Haas suggested that if we're going to customize by platform, we should
show only meaningful values per platform [2]. Nobody followed through
with a patch.

Problem

Windows administrators get this:
! 0/0 [0/0] filesystem blocks in/out
! 0/39 [0/1281] page faults/reclaims, 0 [0] swaps

The zeros are uninformative. Windows has the data - I/O byte counts,
detailed memory stats, handle counts - but we're trying to jam it into
struct rusage where it doesn't fit.

I propose we let each platform report what it actually measures, using
native APIs:

Windows: GetProcessMemoryInfo, GetProcessIoCounters, QueryProcessCycleTime
Linux/BSD: Keep using getrusage, maybe expose more fields later

This means platform-specific output formats, but that's better than
reporting zeros. This follows the precedent Robert Haas suggested in
2017 [2]: "if we're going to go to the trouble of customizing this code
by platform, we ought to get rid of values that are meaningless on that
platform."

We already have extensive platform-specific code in
src/backend/port/win32/. This follows the same pattern.

I've included a rough proof-of-concept. It:

(1) Adds PgWin32ResourceUsage extension to PGRUsage
(2) Implements Windows-native collection via additions to pg_rusage_init()
(3) Shows actual I/O bytes, memory details, handle/thread counts
(4) Leaves Unix paths completely untouched

On Windows you'd see:
! Memory: 45232 KB working set (48192 KB peak), 38416 KB private
! I/O: 2457600 bytes read (147 ops), 819200 bytes written (43 ops)
! Resources: 247 handles, 8 threads

Before I invest time in a full patch:

(1) Is there support for this general approach of platform-specific
resource reporting?
(2) Should this extend to non-Windows Unix platforms as well (e.g.,
exposing more Linux-specific fields)?
(3) Any concerns about diverging output formats across platforms?
(4) Would you prefer all platforms to show only common fields, or
platform-native output?

I believe this aligns with PostgreSQL's existing philosophy - we already
have extensive platform-specific code in src/backend/port/win32/, and
this would be a natural extension of that approach.

I'm happy to implement this if there's community interest. Feedback welcome!

[1]
https://www.postgresql.org/message-id/20170610222026.GE18003@telsasoft.com
[2] https://www.mail-archive.com/pgsql-hackers(at)postgresql(dot)org/msg316929.html

BG

Attachment Content-Type Size
pg_rusage_win32_poc.patch text/plain 4.6 KB

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2025-10-19 16:57:16 Re: gzgetc() is hazardous to your health
Previous Message Mihail Nikalayeu 2025-10-19 13:41:00 isolation tester limitation in case of multiple injection points in a single command