Re: Command statistics system (cmdstats)

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org>, "Smith, Peter" <peters(at)fast(dot)au(dot)fujitsu(dot)com>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Dilip Kumar <dilipbalaut(at)gmail(dot)com>, vinayak <Pokale_Vinayak_q3(at)lab(dot)ntt(dot)co(dot)jp>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Subject: Re: Command statistics system (cmdstats)
Date: 2020-06-10 17:45:02
Message-ID: CA+Tgmoa-rgWRGgxi4o8W=OdTJ92TO3VkcLBznBKUP0NdHwPUJA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Mar 4, 2020 at 10:43 PM Mark Dilger
<mark(dot)dilger(at)enterprisedb(dot)com> wrote:
> The two main differences are that
>
> (1) This implementation is based on commandtags as enums, not strings and
> (2) This implementation uses techniques to reduce lock contention
>
> I think (2) is the more important part.

My spidey sense is tingling here, telling me that we need some actual
benchmarking. Like, suppose we test the two patches under normal cases
and under cases that are constructed to be as bad as possible for each
of them. Or suppose we test this patch with the lock mitigation
strategies and then remove the mitigations for some inexpensive
command (e.g. SHOW) and then use pgbench to spam that command. Like
you, I suspect that the locking mitigations are important in some
workloads, but it would be good to have some figures to back that out,
as well as to find out whether there's still too much overhead.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alexey Kondratov 2020-06-10 17:57:17 Re: Physical replication slot advance is not persistent
Previous Message Bruce Momjian 2020-06-10 17:40:45 Re: Internal key management system