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. 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. 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