| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Magnus Hagander <magnus(at)hagander(dot)net>, Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com>, Georgios <gkokolatos(at)protonmail(dot)com>, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: shared-memory based stats collector |
| Date: | 2021-04-03 03:51:59 |
| Message-ID: | 20210403035159.b3cxlkra3qxt5jxc@alap3.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
On 2021-03-16 12:54:40 -0700, Andres Freund wrote:
> I did consider command_progress.c too - but that seems confusing because
> there's src/include/commands/progress.h, which is imo a different layer
> than what pgstat/backend_progress provide. So I thought splitting things
> up so that backend_progress.[ch] provide the place to store the progress
> values, and commands/progress.h defining the meaning of the values as
> used for in-core postgres commands would make sense. I could see us
> using the general progress infrastructure for things that'd not fit
> super well into commands/* at some point...
Thinking about it some more, having the split between backend_status.h
and commands/progress.h actually makes a fair bit of sense from another
angle: Commands utilizing workers. backend_status.h provides
infrastructure to store progress counters for a single backend, but
multiple backends can participate in a command...
I added some comments to the header to that end.
Greetings,
Andres Freund
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Joel Jacobson | 2021-04-03 05:13:34 | Re: [PATCH] Implement motd for PostgreSQL |
| Previous Message | Julien Rouhaud | 2021-04-03 03:39:43 | Re: SQL-standard function body |