On 08/11/14 00:35, Robert Haas wrote:
On Nov 5, 2014, at 7:31 PM, Steve Singer <st...@ssinger.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


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to