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

Re: Range types

From: Scott Bailey <artacus(at)comcast(dot)net>
Cc: hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Range types
Date: 2009-12-15 19:31:05
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Jeff Davis wrote:
> On Tue, 2009-12-15 at 10:19 -0500, Tom Lane wrote:
>> I'm not sure that anyone has argued that.  I did suggest that there
>> might be a small list of types for which we should provide discrete
>> behavior (ie, with next/previous functions) and the rest could have
>> continuous behavior (without that assumption).  But I quite agree
>> that we want both types of ranges.
> It seems like we're moving toward treating TIMESTAMP as continuous.
> If I'm correct, continuous ranges always need two extra bits of storage
> for the exclusivity. But for timestamps, that means 16 bytes (2 x 8-byte
> timestamp) turns into 17 bytes, which is really more like 20 or 24 bytes
> with alignment.
> Considering that these are likely to be used for audit or history
> tables, 8 bytes of waste (50%) seems excessive -- especially when
> treating them as discrete seems to work pretty well, at least for the
> int64 timestamps.

Would it be OK if we handled float timestamp ranges as continuous and 
int64 timestamps discrete? You effectively lose the ability to build 
non-contiguous sets with continuous ranges. Which is integral to the 
work I'm doing (union, intersect, coalesce and minus sets of ranges)

As for the extra bits, would it be better to just require continuous 
ranges to be either [] or [)? But I don't know which would be preferred. 
My inclination would be toward [), but Tom seemed to indicate that 
perhaps [] was the norm.


In response to


pgsql-hackers by date

Next:From: Greg SmithDate: 2009-12-15 19:44:36
Subject: Re: Closing out CommitFest 2009-11
Previous:From: Kevin GrittnerDate: 2009-12-15 19:02:34
Subject: Update on true serializable techniques in MVCC

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