Re: Stats collector performance improvement
От | Hannu Krosing |
---|---|
Тема | Re: Stats collector performance improvement |
Дата | |
Msg-id | 1136324574.4256.17.camel@localhost.localdomain обсуждение исходный текст |
Ответ на | Re: Stats collector performance improvement (Simon Riggs <simon@2ndquadrant.com>) |
Ответы |
Re: Stats collector performance improvement
|
Список | pgsql-hackers |
Ühel kenal päeval, T, 2006-01-03 kell 09:40, kirjutas Simon Riggs: > We can also save lots of cycles on the current statement overhead, which > is currently the worst part of the stats, performance-wise. That > definitely needs redesign. AFAICS we only ever need to know the SQL > statement via the stats system if the statement has been running for > more than a few minutes - the main use case is for an admin to be able > to diagnose a rogue or hung statement. Interestingly I use pg_stat_activity view to watch for stuck backends, "stuck" in the sense that they have not noticed when client want away and are now waitin the TCP timeout to happen. I query for backends which have been in "<IDLE>" state for longer than XX seconds. I guess that at least some kind of indication for this should be available. Of course this would be much less of a problem if there was a possibility for sime kind of keepalive system to detect when client/frontend goes away. > Pushing the statement to stats > every time is just a big overhead. That suggests we should either have a > pull I could live with "push", where pg_stat_activity would actually ask each live backend for its "current query". This surely happens less often than queries are performed (up to few thousand per sec) ------------- Hannu
В списке pgsql-hackers по дате отправления: