Re: shared-memory based stats collector

Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp> wrote:

> This is more saner version of previous v5-0008, which didn't pass
> regression test. v6-0008 to v6-0010 are attached and they are
> applied on top of v5-0001-0007.
>
> - stats collector has been removed.
>
> - modified dshash further so that deletion is allowed during
> sequential scan.
>
> - I'm not sure about the following existing comment at the
> beginning of pgstat.c
>
> * - Add a pgstat config column to pg_database, so this
> * entire thing can be enabled/disabled on a per db basis.

Following is the next handful of my comments:

* If you remove the stats collector, I think the remaining code in pgstat.c
does no longer fit into the backend/postmaster/ directory.

* I'm not sure it's o.k. to call pgstat_write_statsfiles() from
postmaster.c:reaper(): the function can raise ERROR (I see at least one code
path: pgstat_write_statsfile() -> get_dbstat_filename()) and, as reaper() is
a signal handler, it's hard to imagine the consequences. Maybe a reason to
leave some functionality in a separate worker, although the "stats
collector" would have to be changed.

* Question still remains whether all the statistics should be loaded into
shared memory, see the note on paging near the bottom of [1].

* if dshash_seq_init() is passed consistent=false, shouldn't we call
ensure_valid_bucket_pointers() also from dshash_seq_next()? If the scan
needs to access the next partition and the old partition lock got released,
the table can be resized before the next partition lock is acquired, and
thus the backend-local copy of buckets becomes obsolete.

* Neither snapshot_statentry_all() nor backend_snapshot_all_db_entries() seems
to be used in the current patch version.

* pgstat_initstats(): I think WaitLatch() should be used instead of sleep().

* pgstat_get_db_entry(): "return false" should probably be "return NULL".

* Is the PGSTAT_TABLE_WRITE flag actually used? Unlike PGSTAT_TABLE_CREATE, I
couldn't find a place where it's value is tested.

* dshash_seq_init(): does it need to be called with consistent=true from
pgstat_vacuum_stat() when the the entries returned by the scan are just
dropped?

dshash_seq_init(&dshstat, db_stats, true, true);

I suspect this is a thinko because another call from the same function looks
like

dshash_seq_init(&dshstat, dshtable, false, true);

* I'm not sure about usefulness of dshash_get_num_entries(). It passes
consistent=false to dshash_seq_init(), so the number of entries can change
during the execution. And even if the function requested a "consistent
scan", entries can be added / removed as soon as the scan is over.

If the returned value is used to decide whether the hashtable should be
scanned or not, I think you don't break anything if you simply start the
scan unconditionally and see if you find some entries.

And if you really need to count the entries, I suggest that you use the
per-partition counts (dshash_partition.count) instead of scanning individual
entries.

[1] https://www.postgresql.org/message-id/CA+TgmobQVbz4K_+RSmiM9HeRKpy3vS5xnbkL95gSEnWijzprKQ@mail.gmail.com

--
Antonin Houska
Cybertec Schönig & Schönig GmbH
Gröhrmühlgasse 26, A-2700 Wiener Neustadt
Web: https://www.cybertec-postgresql.com