Sorry for the confusing description and the chopped sentsnce. At Tue, 01 Dec 2015 16:25:57 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI <horiguchi.kyot...@lab.ntt.co.jp> wrote in <20151201.162557.184519961.horiguchi.kyot...@lab.ntt.co.jp> > Hello, > > At Mon, 30 Nov 2015 19:10:44 -0700 (MST), Vinayak <vinpok...@gmail.com> wrote > in <1448935844520-5875614.p...@n5.nabble.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
