Re: Sample rate added to pg_stat_statements
От | Sami Imseih |
---|---|
Тема | Re: Sample rate added to pg_stat_statements |
Дата | |
Msg-id | CAA5RZ0vYu+dm3KKd5iaQ=LY0J2sjfxJG+-VCfkeVtWFuhSb-4A@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Sample rate added to pg_stat_statements ("Andrey M. Borodin" <x4mmm@yandex-team.ru>) |
Список | 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 по дате отправления: