Skip site navigation (1) Skip section navigation (2)

Re: xlog location arithmetic

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Euler Taveira de Oliveira <euler(at)timbira(dot)com>
Cc: Magnus Hagander <magnus(at)hagander(dot)net>, Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: xlog location arithmetic
Date: 2011-12-06 18:06:36
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Tue, Dec 6, 2011 at 1:00 PM, Euler Taveira de Oliveira
<euler(at)timbira(dot)com> wrote:
> On 06-12-2011 13:11, Robert Haas wrote:
>> On Tue, Dec 6, 2011 at 5:14 AM, Magnus Hagander <magnus(at)hagander(dot)net> wrote:
>>> I've been considering similar things, as you can find in the archives,
>>> but what I was thinking of was converting the number to just a plain
>>> bigint, then letting the user apply whatever arithmetic wanted at the
>>> SQL level. I never got around to acutally coding it, though. It could
>>> easily be extracted from your patch of course - and I think that's a
>>> more flexible approach. Is there some advantage to your method that
>>> I'm missing?
>> I went so far as to put together an lsn data type.  I didn't actually
>> get all that far with it, which is why I haven't posted it sooner, but
>> here's what I came up with.  It's missing indexing support and stuff,
>> but that could be added if people like the approach.  It solves this
>> problem by implementing -(lsn,lsn) => numeric (not int8, that can
>> overflow since it is not unsigned), which allows an lsn => numeric
>> conversion by just subtracting '0/0'::lsn.
> Interesting approach. I don't want to go that far. If so, you want to change
> all of those functions that deal with LSNs and add some implicit conversion
> between text and lsn data types (for backward compatibility). As of int8, I'm
> not aware of any modern plataform that int8 is not 64 bits. I'm not against
> numeric use; I'm just saying that int8 is sufficient.

The point isn't that int8 might not be 64 bits - of course it has to
be 64 bits; that's why it's called int8 i.e. 8 bytes.  The point is
that a large enough LSN, represented as an int8, will come out as a
negative values.  int8 can only represent 2^63 *non-negative* values,
because one bit is reserved for sign.

Robert Haas
The Enterprise PostgreSQL Company

In response to


pgsql-hackers by date

Next:From: Tom LaneDate: 2011-12-06 18:07:08
Subject: Re: Inlining comparators as a performance optimisation
Previous:From: Euler Taveira de OliveiraDate: 2011-12-06 18:00:51
Subject: Re: xlog location arithmetic

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group