Re: shared-memory based stats collector

At Fri, 15 Feb 2019 17:29:00 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp> wrote in <20190215(dot)172900(dot)84235698(dot)horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>
> > I don't think this is all that close to being committable :(
>
> I'm going to work harder on this. The remaining taks just now are
> the follows:
>
> - Separte shared database stats from db_stats hash.

Finally I didn't do that. It lead to more complexy.

> - Consider relaxing dbentry locking.

Lock on a dbenty by dshash was useless to protect it from DROP
DB, so I relaxed locking on dbentry so that the dshash lock is
immediately released after fetching it. On the other hand table
and function counter hash are just destroyed at the time of a
counter reset ant it required some kind of arbitration. I could
introduce dshash_reset() but it requires many lwlocks, which
would be too-much. Instaed, I inroduced two-set of hash_handles
and reference counter in PgStat_StatDBEntry to stash out
to-be-removed-but-currently-accessed hash. pin_hashes() and
unpin_hashes(), and reset_dbentry_counters() are that.

After all, dbentries are no longer isolated by dshash partition
lock on updates, so every dbentry instead has LWLock to do
that. (tabentries/funcentries are still isolated by dshash).

pgstat_apply_tabstats() runs single-pass. Previously ran
two-passes, shared db and my database.

We could eliminate pgStatPendingTabHash, but manipulating TSA

I'm trying removing pgStatPendingTabHash it does't work yet. I'll
include it in the next version.

> - Try removing pgStatPendingFunctions

Done. pgStatPendingDeadLocks and pgStatPendingTempfiles are also
removed.

> - ispell on it.

I fixed many misspellings..

- Fixed several silly mistakes in the previous version.

I'll post the next version soon.

regards.

--
Kyotaro Horiguchi
NTT Open Source Software Center