| 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
| 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 |