Re: [PROPOSAL] VACUUM Progress Checker.

Sorry for the confusing description and the chopped sentsnce.

At Tue, 01 Dec 2015 16:25:57 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp> wrote in <20151201(dot)162557(dot)184519961(dot)horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>
> Hello,
>
> At Mon, 30 Nov 2015 19:10:44 -0700 (MST), Vinayak <vinpokale(at)gmail(dot)com> wrote in <1448935844520-5875614(dot)post(at)n5(dot)nabble(dot)com>
> > Thanks for the v7.
> > Please check the comment below.
> > -Table name in the vacuum progress
> >
> > + snprintf(progress_message[0], PROGRESS_MESSAGE_LENGTH, "%s.%s",
> > schemaname,relname);
> >
> > In the vacuum progress, column table_name is showing first 30 characters of
> > table name.
>
> Yeah, it is actually restricted in that length. But if we allow
> the buffer to store whole the qualified names, it will need 64 *
> 2 + 1 +1 = 130 bytes * 10 1300 bytes for each beentry... It might
> be acceptable by others, but I don't think that is preferable..
>
> Separating namespace and relation name as below reduces the
> required length of the field but 62 bytes is still too long for
> most of the information and in turn too short for longer messages
> in some cases.
>
> As a more dractic change in design, since these fields are
> written/read in sequential manner, providing one free buffer of
> the size of.. so.. about 128 bytes for each beentry and storing
> strings delimiting with '\0' and numbers in binary format, as an
> example, would do.

This would fail to make sense.. I suppose this can be called
'packed format', as opposed to fixed-length format. Sorry for
poor wording.

> Additional functions to write into/read from
> this buffer safely would be needed but this gives both the
> ability to store longer messages and relatively short total
> buffer size, and allows arbitrary number of parameters limited
> only by the length of the free buffer.
>
> What do you think about this?
>
>
> By the way, how about giving separate columns for relname and
> namespace? I think it is more usual way to designate a relation
> in this kind of view and it makes the snprintf to concatenate
> name and schema unnecessary(it's not significant, though). (The
> following example is after pg_stat_all_tables)
>
> > postgres=# create table test_vacuum_progress_in_postgresql(c1 int,c2 text);
> > postgres=# select * from pg_stat_vacuum_progress ;
> > pid | 12284
> > schemaname | public
> > relname | test_vacuum_progress_i...
> > phase | Scanning Heap
> > total_heap_pages | 41667
> ...
>
>
> And I have some comments about code.

This is just what I forgot to delete. I'll mention them later if
necessary.

regards,

--
Kyotaro Horiguchi
NTT Open Source Software Center