From: | Neil Conway <neilc(at)samurai(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Magnus Hagander <mha(at)sollentuna(dot)net>, Jan Wieck <JanWieck(at)Yahoo(dot)com>, PostgreSQL-patches <pgsql-patches(at)postgresql(dot)org> |
Subject: | Re: Added columns to pg_stat_activity |
Date: | 2005-05-09 02:04:18 |
Message-ID: | 427EC522.4010807@samurai.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-patches |
Tom Lane wrote:
> I think this argument is a red herring ... or at least it leads in a
> direction I find unacceptable.
I agree -- I was just pointing out the reason that, in the current
design, there is cause to do things as Magnus' original patch did.
> We are already transmitting three more fields than necessary in every
> MsgHdr --- PID, database OID, and user ID --- and it will only get
> worse if we go down this path.
How about changing the statistics collector so that we only include a
row in the statistics view when we receive the BESTART message? That
would mean the BESTART message could include backend-start metadata
(user ID, database ID, client address), and all other messages would
only need enough header data to identify the backend process they are
associated with (so perhaps backend id and process id).
Using the existing dead-backend hash table, we should be able to
distinguish between the cases of "seen a message for a new backend
before receiving its BESTART" and "seen a message for a dead backend
after we've seen its BETERM".
-Neil
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2005-05-09 02:24:19 | Re: Added columns to pg_stat_activity |
Previous Message | Tom Lane | 2005-05-09 01:26:53 | Re: Added columns to pg_stat_activity |