Re: tracking commit timestamps

On 08/11/14 00:35, Robert Haas wrote:
>> On Nov 5, 2014, at 7:31 PM, Steve Singer <steve(at)ssinger(dot)info> wrote:
>>> On 11/05/2014 05:43 PM, Andres Freund wrote:
>>> On 2014-11-05 17:17:05 -0500, Steve Singer wrote:
>>> Imo that's essentially a different feature. What you essentially would
>>> need here is a 'commit sequence number' - but no timestamps. And
>>> probably to be useful that number has to be 8 bytes in itself.
>>
>> I think this gets to the heart of some of the differing views people have expressed on this patch
>>
>> Is this patch supposed to:
>>
>> A) Add commit timestamp tracking but nothing more
>>
>> B) Add infrastructure to store commit timestamps and provide a facility for storing additional bits of data extensions might want to be associated with the commit
>>
>> C). Add commit timestamps and node identifiers to commits
>
> Well put.
>
> I think the authors of this patch are suffering from a certain amount of myopia. Commit timestamps are useful, but so are commit LSNs, and it makes little sense to me to suppose that we should have two different systems for those closely-related needs.
>
> Like Andres, I think B is impractical, so let's just be honest and admit that C is what we're really doing. But let's add LSNs so the people who want that can be happy too.
>

The list of what is useful might be long, but we can't have everything
there as there are space constraints, and LSN is another 8 bytes and I
still want to have some bytes for storing the "origin" or whatever you
want to call it there, as that's the one I personally have biggest
use-case for.
So this would be ~24bytes per txid already, hmm I wonder if we can pull
some tricks to lower that a bit.

--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services