Re: [PROPOSAL] VACUUM Progress Checker.

Hello, sorry for the cloberred CC list.

# I restored it manually from upthread..

At Wed, 2 Dec 2015 13:42:01 -0500, Robert Haas <robertmhaas@gmail.com> wrote in
<CA+TgmobcN=3qa9X7c8_G18x53HDCpEYbWP4tnR_es5d=tYvrkQ@mail.gmail.com>
> On Tue, Dec 1, 2015 at 2:25 AM, Kyotaro HORIGUCHI
> <horiguchi.kyotaro@lab.ntt.co.jp> wrote:
> > 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..
> 
> There's no such thing as a free lunch here, but we probably don't need
> room for 10 strings.  If we allowed say 4 strings per beentry and
> limited each one to, say, 140 characters for Twitter-compatibility,
> that's 560 bytes per backend.  Throw in some int8 counters and you're
> up to maybe 600 bytes per backend.  So that's ~60kB of memory for 100
> backends.  That doesn't sound like a huge problem to me, but it
> wouldn't be stupid to have a PGC_POSTMASTER GUC to turn this feature
> on and off, for the benefit of people who may want to run this in
> low-memory environments.

This is similar to Amit-L's proposal and either sound fair for me.

> > 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. 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?
> 
> I think it sounds like a mess with uncertain benefits.  Now instead of
> having individual fields that maybe don't fit and have to be
> truncated, you have to figure out what to leave out when the overall
> message doesn't fit.  That's likely to lead to a lot of messy logic on
> the server side, and even messier logic for any clients that read the
> data and try to parse it programmatically.

Ok, I understood that the packed format itself is unaccetable.

> > 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)
> 
> I could go either way on this.

It would depends on the field length but 140 bytes can hold a
whole qualified names.

regards,

-- 
Kyotaro Horiguchi
NTT Open Source Software Center