From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Rahila Syed <rahilasyed90(at)gmail(dot)com> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [PROPOSAL] VACUUM Progress Checker. |
Date: | 2015-08-18 15:05:47 |
Message-ID: | CA+TgmoYV-Q9YxJ4QSmPhxNF8_JtORbtUAY0a2VHEL85hBtmoiA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Aug 10, 2015 at 12:36 AM, Rahila Syed <rahilasyed90(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2015-08-18 15:12:36 | Re: Our trial to TPC-DS but optimizer made unreasonable plan |
Previous Message | Robert Haas | 2015-08-18 14:07:32 | Re: allowing wal_level change at run time |