Re: [PERFORM] Impact of track_activity_query_size on high trafficOLTP system

Поиск
Список
Период
Сортировка
От Rick Otten
Тема Re: [PERFORM] Impact of track_activity_query_size on high trafficOLTP system
Дата
Msg-id CAMAYy4LzMe2=b4y1TCHp060ggAaz8RnuYfGuG3aS1HohZiJt0w@mail.gmail.com
обсуждение исходный текст
Ответ на [PERFORM] Impact of track_activity_query_size on high traffic OLTP system  (Jeremy Finzel <finzelj@gmail.com>)
Список pgsql-performance
I always bump it up, but usually just to 4096, because I often have queries that are longer than 1024 and I'd like to be able to see the full query.   I've never seen any significant memory impact.   I suppose if you had thousands of concurrent queries it would add up, but if you only have a few dozen, or even a few hundred queries at any given moment - on a modern system it doesn't seem to impact things very much.


On Thu, Apr 13, 2017 at 4:45 PM, Jeremy Finzel <finzelj@gmail.com> wrote:
I have found some examples of people tweaking this parameter track_activity_query_size to various setting such as 4000, 10000, 15000, but little discussion as to performance impact on memory usage.  What I don't have a good sense of is how significant this would be for a high traffic system with rapid connection creation/destruction, say 1000s per second.  In such a case, would there be a reason to hesitate raising it to 10000 from 1024?  Is 10k memory insignificant?  Any direction here is much appreciated, including a good way to benchmark this kind of thing.

Thanks!

В списке pgsql-performance по дате отправления:

Предыдущее
От: Jeremy Finzel
Дата:
Сообщение: [PERFORM] Impact of track_activity_query_size on high traffic OLTP system
Следующее
От: Hans Braxmeier
Дата:
Сообщение: [PERFORM] Postgres 9.5 / 9.6: Restoring PG 9.4 dump is very very slow