Re: [PROPOSAL] VACUUM Progress Checker.

From: Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>
To: Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>
Cc: alvherre(at)2ndquadrant(dot)com, rahilasyed90(at)gmail(dot)com, Jim(dot)Nasby(at)bluetreble(dot)com, pgsql-hackers(at)postgresql(dot)org, masao(dot)fujii(at)gmail(dot)com, sawada(dot)mshk(at)gmail(dot)com, thom(at)linux(dot)com, pokurev(at)pm(dot)nttdata(dot)co(dot)jp, robertmhaas(at)gmail(dot)com, vinpokale(at)gmail(dot)com
Subject: Re: [PROPOSAL] VACUUM Progress Checker.
Date: 2015-12-07 07:41:37
Message-ID: 56653831.1040502@lab.ntt.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


Hi,

On 2015/12/03 19:05, Kyotaro HORIGUCHI wrote:
> At Thu, 3 Dec 2015 16:24:32 +0900, Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp> wrote
>> By the way, there are some non-st_progress_* fields that I was talking
>> about in my previous message. For example, st_activity_flag (which I have
>> suggested to rename to st_command instead). It needs to be set once at the
>> beginning of the command processing and need not be touched again. I think
>> it may be a better idea to do the same for table name or OID. It also
>> won't change over the duration of the command execution. So, we could set
>> it once at the beginning where that becomes known. Currently in the patch,
>> it's reported in st_progress_message[0] by every pgstat_report_progress()
>> invocation. So, the table name will be strcpy()'d to shared memory for
>> every scanned block that's reported.
>
> If we don't have dedicate reporting functions for each phase
> (that is, static data phase and progress phase), the one function
> pgstat_report_progress does that by having some instruction from
> the caller and it would be a bitfield.
>
> Reading the flags for making decision whether every field to copy
> or not and branching by that seems too much for int32 (or maybe
> 64?) fields. Alhtough it would be in effective when we have
> progress_message fields, I don't think it is a good idea without
> having progress_message.
>
>> pgstat_report_progress(uint32 *param1, uint16 param1_bitmap,
>> char param2[][..], uint16 param2_bitmap)
>> {
>> ...
>> for(i = 0; i < 16 ; i++)
>> {
>> if (param1_bitmap & (1 << i))
>> beentry->st_progress_param[i] = param1[i];
>> if (param2_bitmap & (1 << i))
>> strcpy(beentry->..., param2[i]);
>> }
>
> Thoughts?

Hm, I guess progress messages would not change that much over the course
of a long-running command. How about we pass only the array(s) that we
change and NULL for others:

With the following prototype for pgstat_report_progress:

void pgstat_report_progress(uint32 *uint32_param, int num_uint32_param,
bool *message_param[], int num_message_param);

If we just wanted to change, say scanned_heap_pages, then we report that
using:

uint32_param[1] = scanned_heap_pages;
pgstat_report_progress(uint32_param, 3, NULL, 0);

Also, pgstat_report_progress() should check each of its parameters for
NULL before iterating over to copy. So in most reports over the course of
a command, the message_param would be NULL and hence not copied.

Thanks,
Amit

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2015-12-07 07:41:52 Re: Making tab-complete.c easier to maintain
Previous Message Amit Langote 2015-12-07 06:28:09 Re: [sqlsmith] Failed to generate plan on lateral subqueries