Re: shared-memory based stats collector

Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.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