| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Dmitry Dolgov <9erthalion6(at)gmail(dot)com> |
| Cc: | Bertrand Drouvot <bertranddrouvot(dot)pg(at)gmail(dot)com>, Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Pluggable cumulative statistics |
| Date: | 2024-07-28 13:20:45 |
| Message-ID: | ZqZFrRyf_7uFqcQ6@paquier.xyz |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Sat, Jul 27, 2024 at 03:49:42PM +0200, Dmitry Dolgov wrote:
> Agree, looks good. I've tried to quickly sketch out such a fixed
> statistic for some another extension, everything was fine and pretty
> straightforward.
That's my hope. Thanks a lot for the feedback.
> One question, why don't you use
> pgstat_get_custom_shmem_data & pgstat_get_custom_snapshot_data outside
> of the injection points code? There seems to be a couple of possible
> places in pgstats itself.
Because these two helper routines are only able to fetch the fixed
data area in the snapshot and the control shmem structures for the
custom kinds, not the in-core ones. We could, but the current code is
OK as well. My point was just to ease the pluggability effort.
I would like to apply this new infrastructure stuff and move on to the
problems related to the scability of pg_stat_statements. So, are
there any objections with all that?
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Chapman Flack | 2024-07-28 14:34:53 | Re: pg_attribute.atttypmod for interval type |
| Previous Message | David Rowley | 2024-07-28 10:34:49 | Re: Fix overflow in pg_size_pretty |