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-04 20:20:30 |
Message-ID: | 4C09600E.6080501@Yahoo.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 6/4/2010 12:52 PM, Alvaro Herrera wrote:
> Excerpts from Jan Wieck's message of jue jun 03 19:52:19 -0400 2010:
>> On 6/3/2010 7:11 PM, Alvaro Herrera wrote:
>
>> > 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.
>
> But we already have per table counters. Couldn't we aggregate them per
> transaction as well, if this feature is enabled? I'm guessing that this
> is going to have some uses besides Slony; vague measurements could turn
> out to be unusable for some of these.
We have them per table and per index, summarized over all transactions.
It is debatable if bloating this feature with detailed statistics is
useful or not, but I'd rather not have that bloat at the beginning,
because otherwise I know exactly what is going to happen. People will
just come back and say "zero impact my a..".
Jan
--
Anyone who trades liberty for security deserves neither
liberty nor security. -- Benjamin Franklin
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2010-06-04 20:22:38 | Re: Synchronization levels in SR |
Previous Message | Tom Lane | 2010-06-04 20:18:58 | Re: Idea for getting rid of VACUUM FREEZE on cold pages |