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. > 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. > 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. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
