Re: Sample rate added to pg_stat_statements - Mailing list pgsql-hackers

From Sami Imseih
Subject Re: Sample rate added to pg_stat_statements
Date
Msg-id CAA5RZ0vYu+dm3KKd5iaQ=LY0J2sjfxJG+-VCfkeVtWFuhSb-4A@mail.gmail.com
Whole thread Raw
In response to Re: Sample rate added to pg_stat_statements  ("Andrey M. Borodin" <x4mmm@yandex-team.ru>)
List pgsql-hackers
> Alena, Sami – I apologize for not including you in the previous email.
> If you're interested in this approach, I'm open to any suggestions.
>
> [0]:
> https://www.postgresql.org/message-id/1b13d748-5e98-479c-9222-3253a734a038%40tantorlabs.com

Here are my thoughts on this:

There is good reason to apply sample rate selectively,
but I am not sure if execution time is the way to go. I
would rather apply a sample rate on the most frequently
called queries, since I can gather enough samples
to draw conclusions about performance of the query.
I just don't know if that can be done in a sensible way,
because while we can check the number of calls in the entry,
we will need to do that with a shared lock and spin lock,
which will defeat the purpose of this patch.

This also got me thinking if maybe we should
allow the user to disable sample rate for
utility statements as those are less frequent
in most workloads and a user may want to capture
all such statements, i.e. DROP, CREATE, etc.

Regards,

Sami



pgsql-hackers by date:

Previous
From: Peter Smith
Date:
Subject: Re: Log a warning in pg_createsubscriber for max_slot_wal_keep_size
Next
From: Andres Freund
Date:
Subject: Re: Reorder shutdown sequence, to flush pgstats later