Re: [PROPOSAL] VACUUM Progress Checker.
От | Robert Haas |
---|---|
Тема | Re: [PROPOSAL] VACUUM Progress Checker. |
Дата | |
Msg-id | CA+TgmoYV-Q9YxJ4QSmPhxNF8_JtORbtUAY0a2VHEL85hBtmoiA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [PROPOSAL] VACUUM Progress Checker. (Rahila Syed <rahilasyed90@gmail.com>) |
Список | pgsql-hackers |
On Mon, Aug 10, 2015 at 12:36 AM, Rahila Syed <rahilasyed90@gmail.com> wrote: > Hello, > >>Say, 6 bigint counters, 6 float8 >>counters, and 3 strings up to 80 characters each. So we have a >>fixed-size chunk of shared memory per backend, and each backend that >>wants to expose progress information can fill in those fields however >>it likes, and we expose the results. >>This would be sorta like the way pg_statistic works: the same columns >>can be used for different purposes depending on what estimator will be >>used to access them. > > After thinking more on this suggestion, I came up with following generic > structure which can be used to store progress of any command per backend in > shared memory. > > Struct PgBackendProgress > { > int32 *counter[COMMAND_NUM_SLOTS]; > float8 *counter_float[COMMAND_NUM_SLOTS]; > > char *progress_message[COMMAND_NUM_SLOTS]; > } This can't actually work, because we don't have a dynamic allocator for shared memory. What you need to do is something like this: struct PgBackendProgress { uint64 progress_integer[N_PROGRESS_INTEGER]; float8 progress_float[N_PROGRESS_FLOAT]; char progress_string[PROGRESS_STRING_LENGTH][N_PROGRESS_STRING]; }; You probably want to protect this with the st_changecount protocol, or just put the fields in PgBackendStatus. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: