Re: shared-memory based stats collector

It occurred to my mind the fact that I forgot to mention the most
significant outcome of this patch.

At Thu, 08 Oct 2020 16:03:26 +0900 (JST), Kyotaro Horiguchi <horikyota.ntt@gmail.com> wrote in 
> At Tue, 06 Oct 2020 10:06:44 +0900 (JST), Kyotaro Horiguchi <horikyota.ntt@gmail.com> wrote in 
> > The previous version failed to flush local database stats for certain
> > condition. That behavior caused useless retries and finally a forced
> > flush that leads to contention. I fixed that and will measure
> > performance with this version.
> 
> I (we) got some performance numbers.
> 
> - Fetching 1 tuple from 1 of 100 tables from 100 to 800 clients.
> - Fetching 1 tuple from 1 of 10 tables from 100 to 800 clients.
> 
> Those showed speed of over 400,000 TPS at maximum, and no siginificant
> difference is seen between patched and unpatched at the all range of
> the test. I tried 5 seconds as PGSTAT_MIN_INTERVAL (10s in the patch)
> but that made no difference.
> 
> - Fetching 1 tuple from 1 table from 800 clients.
> 
> No graph for this is not attached but this test shows speed of over 42
> TPS with or without the v39 patch.

Under a heavy load and having many tables, the *reader* side takes
seconds ore more time to read the stats table.  With this patch, it
takes almost no time (maybe ms order?) for the same operation.

regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center