Re: [PROPOSAL] VACUUM Progress Checker.
От | Kyotaro HORIGUCHI |
---|---|
Тема | Re: [PROPOSAL] VACUUM Progress Checker. |
Дата | |
Msg-id | 20151203.133622.17317317.horiguchi.kyotaro@lab.ntt.co.jp обсуждение исходный текст |
Ответ на | Re: [PROPOSAL] VACUUM Progress Checker. (Robert Haas <robertmhaas@gmail.com>) |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: