Skip site navigation (1)
Skip section navigation (2)
## Re: xlog location arithmetic

### In response to

### Responses

### pgsql-hackers by date

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 EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company

- Re: xlog location arithmetic at 2011-12-06 18:00:51 from Euler Taveira de Oliveira

- Re: xlog location arithmetic at 2011-12-13 17:48:22 from Jim Nasby
- Re: xlog location arithmetic at 2011-12-20 10:27:41 from Magnus Hagander

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