Re: xlog location arithmetic

From: Jim Nasby <jim(at)nasby(dot)net>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Euler Taveira de Oliveira <euler(at)timbira(dot)com>, Magnus Hagander <magnus(at)hagander(dot)net>, Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: xlog location arithmetic
Date: 2011-12-13 17:48:22
Message-ID: 5A85F6A3-DC6E-41EA-A30D-4993C4805A1D@nasby.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Dec 6, 2011, at 12:06 PM, Robert Haas wrote:
> 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.

I've often wondered about adding uint2/4/8... I suspect it's actually pretty uncommon for people to put negative numbers into int fields, since one of their biggest uses seems to be surrogate keys.

I realize that this opens a can of worms with casting, but perhaps that can be kept under control by not doing any implicit casting between int and uint... that just means that we'd have to be smart about casting from unknown, but hopefully that's doable since we already have a similar concern with casting unknown to int2/4/8 vs numeric?
--
Jim C. Nasby, Database Architect jim(at)nasby(dot)net
512.569.9461 (cell) http://jim.nasby.net

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2011-12-13 17:52:30 Re: Avoiding repeated snapshot computation
Previous Message Tom Lane 2011-12-13 17:48:01 Re: LibreOffice driver 1: Building libpq with Mozilla LDAP instead of OpenLDAP