| From: | Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> |
|---|---|
| To: | samimseih(at)gmail(dot)com |
| Cc: | michael(at)paquier(dot)xyz, lukas(at)fittl(dot)com, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Improve pg_stat_statements scalability |
| Date: | 2026-07-16 04:54:23 |
| Message-ID: | 20260716.135423.1181957553378153013.horikyota.ntt@gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hello,
I'm a bit concerned that this exposes some of the underlying dshash
implementation details to stats kinds. I'd prefer to keep those
details encapsulated if possible. That said, considering the
performance implications, I can understand the direction taken by this
series.
0003:
> +bool
> +pgstat_drop_current(PgStatShared_HashEntry *shent, dshash_seq_status *hstat)
However, pgstat_drop_current() seems too tightly coupled to the state
of the underlying dshash scan. shent must be the current entry of
exactly the scan represented by hstat, but that relationship is not
expressed by the API.
As far as I can see, the function only combines two operations:
releasing a local entry reference, if any, and calling
pgstat_drop_entry_internal() for the current scan entry. Would it be
better to keep these as separate operations, perhaps by adding a small
helper for releasing the local entry reference, rather than combining
them into pgstat_drop_current()?
> +bool
> +pgstat_has_pending(PgStatShared_HashEntry *shent)
I also wonder if this should be added at this point.
The name is rather vague, and the function is not used anywhere in
this series. Unless there is an immediate caller, I'd be inclined to
leave it out for now and add it later if a concrete need arises.
Regards,
--
Kyotaro Horiguchi
NTT Open Source Software Center
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Srinath Reddy Sadipiralla | 2026-07-16 05:06:49 | Re: Fix "unexpected logical decoding status change" error; from concurrent logical decoding activation |
| Previous Message | Fujii Masao | 2026-07-16 04:46:26 | Re: doc: REPACK is missing from the MAINTAIN privilege documentation |