Re: Stats collector performance improvement
От | Simon Riggs |
---|---|
Тема | Re: Stats collector performance improvement |
Дата | |
Msg-id | 1136281253.5052.113.camel@localhost.localdomain обсуждение исходный текст |
Ответ на | Re: Stats collector performance improvement (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Stats collector performance improvement
Re: Stats collector performance improvement |
Список | pgsql-hackers |
On Mon, 2006-01-02 at 16:48 -0500, Tom Lane wrote: > The two compromises that were made in the original stats design to make > it fast were (1) stats updates lag behind reality, and (2) some updates > may be missed entirely. Now that we have a couple of years' field > experience with the code, it seems that (1) is acceptable for real usage > but (2) not so much. We decided that the stats update had to occur during execution, in case the statement aborted and row versions were not notified. That means we must notify things as they happen, yet could use a reliable queuing system that could suffer a delay in the stats becoming available. But how often do we lose a backend? Could we simply buffer that a little better? i.e. don't send message to stats unless we have altered at least 10 rows? So we would buffer based upon the importance of the message, not the actual size of the message. That way singleton-statements won't generate the same stats traffic, but we risk losing a buffers worth of row changes should we crash - everything would still work if we lost a few small row change notifications. 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. Pushing the statement to stats every time is just a big overhead. That suggests we should either have a pull or a deferred push (longer-than-X-secs) approach. Best Regards, Simon Riggs
В списке pgsql-hackers по дате отправления: