From: | Jan Wieck <JanWieck(at)Yahoo(dot)com> |
---|---|
To: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
Cc: | Chris Browne <cbbrowne(at)acm(dot)org>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Exposing the Xact commit order to the user |
Date: | 2010-06-03 23:52:19 |
Message-ID: | 4C084033.1080401@Yahoo.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 6/3/2010 7:11 PM, Alvaro Herrera wrote:
> Excerpts from Chris Browne's message of jue jun 03 16:21:35 -0400 2010:
>
>> What this offers is *SOME* idea of how much updating work a particular
>> transaction did. It's a bit worse than you suggest:
>>
>> - If replication triggers have captured tuples, those would get
>> counted.
>>
>> - TOAST updates might lead to extra updates being counted.
>>
>> But back to where you started, I'd anticipate 7 inserts, 7 deletes,
>> and 7 updates being counted as something around 21 updates.
>>
>> And if that included 5 TOAST changes, it might bump up to 26.
>>
>> If there were replication triggers in place, that might bump the count
>> up to 45 (which I chose arbitrarily).
>
> Why not send separate numbers of tuple inserts/updates/deletes, which we
> already have from pgstats?
>
We only have them for the entire database. The purpose of this is just a
guesstimate about what data volume to expect if I were to select all log
from a particular transaction.
This datum isn't critical, just handy for the overall feature to be useful.
Jan
--
Anyone who trades liberty for security deserves neither
liberty nor security. -- Benjamin Franklin
From | Date | Subject | |
---|---|---|---|
Next Message | KaiGai Kohei | 2010-06-04 00:32:03 | Re: [PATCH] Fix leaky VIEWs for RLS |
Previous Message | Jan Wieck | 2010-06-03 23:49:27 | Re: Exposing the Xact commit order to the user |