Re: [PATCH] Increase the maximum value track_activity_query_size
От | Robert Haas |
---|---|
Тема | Re: [PATCH] Increase the maximum value track_activity_query_size |
Дата | |
Msg-id | CA+TgmoZSs4BZ+CQ6x0Vswxhc8A6r78iCNLcJKWLazGWCqKHnYw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [PATCH] Increase the maximum value track_activity_query_size (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [PATCH] Increase the maximum value track_activity_query_size
Re: [PATCH] Increase the maximum value track_activity_query_size |
Список | pgsql-hackers |
On Sat, Dec 21, 2019 at 1:25 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: > > What is the overhead here except the memory consumption? > > The time to copy those strings out of shared storage, any time > you query pg_stat_activity. It seems like you're masterminding this, and I don't know why. It seems unlikely that anyone will raise the value unless they have very long queries, and if those people would rather pay the overhead of copying more data than have their queries truncated, who are we to argue? If increasing the maximum imposed some noticeable cost on installations the kept the default setting, that might well be a good argument for not raising the maximum. But I don't think that's the case. I also suspect that the overhead would be pretty darn small even for people who *do* raise the default setting. It looks to me like both reading and write operations on st_activity_raw stop when they hit a NUL byte, so any performance costs on short queries must come from second-order effects (e.g. the main shared memory segment is bigger, so the OS cache is smaller) which are likely irrelevant in practice. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: