Hi,
On Mon, Mar 10, 2025 at 09:23:50AM +0900, Michael Paquier wrote:
> On Mon, Mar 03, 2025 at 11:54:39AM +0000, Bertrand Drouvot wrote:
> > So it does not look like what we're adding here can be seen as a primary bottleneck
> > but that is probably worth implementing the "have_iostats" optimization attached.
> >
> > Also, while I did not measure any noticeable extra lag, given the fact that
> > pgstat_flush_io() shows at about 5.5% and pgstat_flush_backend() at about 2.5%,
> > that could still make sense to reduce the frequency of the flush calls, thoughts?
>
> - I've spotted a third candidate which looks pretty solid, actually:
> WalSndWaitForWal() before WalSndWait(). This leads to 2.9k reports in
> the whole test suite, with much less contention in the reports. These
> can still be rather frequent, up to ~50 calls per seconds, but that's
> really less than the two others.
>
> Stats data is useful as long as it is possible to get an idea of how
> the system behaves, particularly with a steady workload. More
> frequent reports are useful for spikey data detection, showing more
> noise. Still, too many reports may cause the part gathering the
> reports to become a bottleneck, while we want it to offer hints about
> bottlenecks. So I would argue in favor of a more conservative choice
> in the back branches than what the patch is proposing.
Yeah, fully agree. Anyway, having so many frequent stats reports makes little sense.
> Choice 3 i'm
> quoting above is tempting by design: not too much, still frequent
> enough to offer enough relevant information in the stats.
Yeah, I also agree that we should reduce the number of "reports". I'll look
at the third option.
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
