Re: [Patch] New pg_stat_tablespace view

From: shihao zhong <zhong950419(at)gmail(dot)com>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Bernd Reiß <bd_reiss(at)gmx(dot)at>, Ahmed Gouda <ahmed(dot)gouda(at)cybertec(dot)at>, Zsolt Parragi <zsolt(dot)parragi(at)percona(dot)com>, songjinzhou <tsinghualucky912(at)foxmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, jian he <jian(dot)universality(at)gmail(dot)com>
Subject: Re: [Patch] New pg_stat_tablespace view
Date: 2026-09-21 15:41:10
Message-ID: CAGRkXqTTQ6pzTs1fKdUE+pzUHWryF5OQVVS9oZWUMV18wxa-fw@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi Andres,

Thanks for looking.

> I am not on board to add duplicate counting to add these places

The clock is already read only once, but you are right that each site still
makes a second call. That should go.

What I would like to do instead is count it in one place, inside
pgstat_count_io_op_time(), right next to pgstat_count_backend_io_op_time().
I would add a variant of that function that takes the tablespace OID, and
keep the current one as a wrapper, so the WAL callers are not touched.

> particularly not if that requires a hash table lookup every single time.

The lookup is in a backend local table, no lock and no shared memory. It
only
runs when track_io_timing is on and a real read or write happened, so it
sits
next to two clock reads and a syscall. If that is still too much, I can
keep a
pointer to the last tablespace used, and the common case becomes one
compare.

> *If* we want this

pg_stat_io cannot tell you which device is slow. With tablespaces on
different storage, that is the first question people ask, and today the only
answer is to go to OS tools and map files back by hand.

Would that shape work for you? I would rather agree on it before sending v8.

Thanks,
Shihao

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Naga Appani 2026-09-21 15:55:02 Re: [Patch] Fix pg_get_multixact_stats() over-reporting members on a hot standby
Previous Message Alvaro Herrera 2026-09-21 15:35:41 Re: Race conditions in logical decoding