Re: Added columns to pg_stat_activity

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

In response to

Responses

Browse pgsql-patches by date

  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