At Mon, 27 Nov 2017 10:03:25 +0900, Michael Paquier <michael.paqu...@gmail.com> wrote in <cab7npqtavwd9vajrzmockhp9k6ge-0u4w_7-yhkz+gyngn8...@mail.gmail.com> > On Mon, Nov 27, 2017 at 5:19 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > > Robert Haas <robertmh...@gmail.com> writes: > >> On Sat, Nov 25, 2017 at 12:09 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > >>> Mumble. It's a property I'm pretty hesitant to give up, especially > >>> since the stats views have worked like that since day one. It's > >>> inevitable that weakening that guarantee would break peoples' queries, > >>> probably subtly. > > > >> You mean, queries against the stats views, or queries in general? If > >> the latter, by what mechanism would the breakage happen? > > > > Queries against the stats views, of course. > > There has been much discussion on this thread, and the set of patches > as presented may hurt performance for users with a large number of > tables, so I am marking it as returned with feedback. > -- > Michael
Hmmm. Okay, we must make stats collector more effeicient if we want to have additional counters with smaller significance in the table stats. Currently sizeof(PgStat_StatTabEntry) is 168 bytes. The whole of the patchset increases it to 232 bytes. Thus the size of a stat file for a database with 10000 tables increases from about 1.7MB to 2.4MB. DSM and shared dynahash is not dynamically expandable so placing stats on shared hash doesn't seem effective. Stats as a regular table could work but it seems too-much. Is it acceptable that adding a new section containing this new counters, which is just loaded as a byte sequence and parsing (and filling the corresponding hash) is postponed until a counter in the section is really requested? The new counters need to be shown in a separate stats view (maybe named pg_stat_vacuum). regards, -- Kyotaro Horiguchi NTT Open Source Software Center
