Re: Feature improvement: can we add queryId for pg_catalog.pg_stat_activity view?
От | Bruce Momjian |
---|---|
Тема | Re: Feature improvement: can we add queryId for pg_catalog.pg_stat_activity view? |
Дата | |
Msg-id | 20201016150449.GA23488@momjian.us обсуждение исходный текст |
Ответ на | Re: Feature improvement: can we add queryId for pg_catalog.pg_stat_activity view? (Julien Rouhaud <rjuju123@gmail.com>) |
Ответы |
Re: Feature improvement: can we add queryId for pg_catalog.pg_stat_activity view?
Re: Feature improvement: can we add queryId for pg_catalog.pg_stat_activity view? |
Список | pgsql-hackers |
On Thu, Oct 15, 2020 at 11:41:23AM +0800, Julien Rouhaud wrote: > On Wed, Oct 14, 2020 at 10:40 PM Bruce Momjian <bruce@momjian.us> wrote: > > There is that, and log_line_prefix, which I can imaging being useful. > > My point is that if the queryid is visible, there should be a reason it > > defaults to show empty. > > I did some naive benchmarking. Using a custom pgbench script with this query: > > SELECT * > FROM pg_class c > JOIN pg_attribute a ON a.attrelid = c.oid > ORDER BY 1 DESC > LIMIT 1; > > I can see around 2% overhead (this query is reported with ~ 3ms > latency average). Adding a few joins, overhead goes down to 1%. That number is too high to enable this by default. I suggest we either improve the performance of this, or clearly document that you have to enable the hash computation to see the pg_stat_activity and log_line_prefix fields. -- Bruce Momjian <bruce@momjian.us> https://momjian.us EnterpriseDB https://enterprisedb.com The usefulness of a cup is in its emptiness, Bruce Lee
В списке pgsql-hackers по дате отправления: