Hello, sorry for the cloberred CC list. # I restored it manually from upthread..
At Wed, 2 Dec 2015 13:42:01 -0500, Robert Haas <robertmh...@gmail.com> wrote in <CA+TgmobcN=3qa9X7c8_G18x53HDCpEYbWP4tnR_es5d=tyv...@mail.gmail.com> > On Tue, Dec 1, 2015 at 2:25 AM, Kyotaro HORIGUCHI > <horiguchi.kyot...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers