Re: tracking commit timestamps

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: Steve Singer <steve(at)ssinger(dot)info>
Cc: Petr Jelinek <petr(at)2ndquadrant(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Andres Freund <andres(at)2ndquadrant(dot)com>, Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Anssi Kääriäinen <anssi(dot)kaariainen(at)thl(dot)fi>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Jaime Casanova <jaime(at)2ndquadrant(dot)com>
Subject: Re: tracking commit timestamps
Date: 2014-11-11 16:20:25
Message-ID: CA+U5nMJnfh6VHd5m-By32-jj=sYkUcQstRQMD-q9u=-US4o=AA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-www

On 9 November 2014 16:57, Steve Singer <steve(at)ssinger(dot)info> wrote:
> On 11/07/2014 07:07 PM, Petr Jelinek wrote:
>
>
>> 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.
>>
>
> The reason why Jim and myself are asking for the LSN and not just the
> timestamp is that I want to be able to order the transactions. Jim pointed
> out earlier in the thread that just ordering on timestamp allows for
> multiple transactions with the same timestamp.
>
> Maybe we don't need the entire LSN to solve that. If you already have the
> commit timestamp maybe you only need another byte or two of granularity to
> order transactions that are within the same microsecond.

It looks like there are quite a few potential uses for this.

If we include everything it will be too fat to use for any of the
potential uses, since each will be pulled down by the others.

Sounds like it needs to be configurable in some way.

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2014-11-11 16:55:41 Re: Missing FIN_CRC32 calls in logical replication code
Previous Message Andres Freund 2014-11-11 16:19:02 Re: tracking commit timestamps

Browse pgsql-www by date

  From Date Subject
Next Message Simon Riggs 2014-11-11 17:09:54 Re: tracking commit timestamps
Previous Message Andres Freund 2014-11-11 16:19:02 Re: tracking commit timestamps