From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Neil Conway <neilc(at)samurai(dot)com> |
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:24:19 |
Message-ID: | 15688.1115605459@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-patches |
Neil Conway <neilc(at)samurai(dot)com> writes:
> How about changing the statistics collector so that we only include a
> row in the statistics view when we receive the BESTART message?
I'd vote against that. The mechanism is lossy by design and so we
must design on the assumption that we will sometimes lose the BESTART
message. I don't think it's acceptable to refuse to display information
we do have (queries, access counts) just because we don't have every
element of a rather-arbitrarily-chosen view row.
> 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).
Looking at the code, backendid seems sufficient since that is the
lookup key.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Neil Conway | 2005-05-09 02:34:07 | Re: Added columns to pg_stat_activity |
Previous Message | Neil Conway | 2005-05-09 02:04:18 | Re: Added columns to pg_stat_activity |