From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | PFC <lists(at)peufeu(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Rethinking stats communication mechanisms |
Date: | 2006-06-17 22:21:14 |
Message-ID: | 24291.1150582874@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
PFC <lists(at)peufeu(dot)com> writes:
> So, the proposal :
> On executing a command, Backend stores the command string, then
> overwrites the counter with (counter + 1) and with the timestamp of
> command start.
> Periodically, like every N seconds, a separate process reads the counter,
> then reads the data, then reads the counter again.
Well, it wouldn't be "periodic", it'd be "whenever someone reads
pg_stat_activity". I was considering solutions like this, but I'm a
little disturbed by the possibility that the would-be reader might
loop indefinitely if the source backend is constantly changing its
entry. Still, slow reads of pg_stat_activity might be a good tradeoff
for taking overhead out of the update operation.
BTW, I think the writer would actually need to bump the counter twice,
once before and once after it modifies its stats area. Else there's
no way to detect that you've copied a partially-updated stats entry.
> If the backend process itself should update its process title, and this
> operation is costly, it should only be done if the current query has been
> running for more than T seconds.
Managing that would cost more than just doing it, I think.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Giampaolo Tomassoni | 2006-06-17 22:27:16 | Per-server univocal identifier |
Previous Message | Martijn van Oosterhout | 2006-06-17 22:18:13 | Re: Exporting type OID macros in a cleaner fashion |