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(dot)ntt(at)gmail(dot)com> wrote in
> At Tue, 06 Oct 2020 10:06:44 +0900 (JST), Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)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