Range types
in [PgSql]
|
Prev: Winflex
Next: [HACKERS] Fast or immediate shutdown
From: Jeff Davis on 15 Dec 2009 12:34 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. Ideas? Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Tom Lane on 15 Dec 2009 13:15 Jeff Davis <pgsql(a)j-davis.com> writes: > 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. You probably need some flag bits anyway, so flailing frantically to avoid that doesn't seem like a profitable use of time. One pretty obvious use for a flag bit is open-ended ranges, ie range(something, infinity) You could only do this without a flag bit if the underlying datatype has an "infinity" value, which not all do. I'm also wondering what null range boundaries would do. Maybe that's the same as the infinity case, or maybe not. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Scott Bailey on 15 Dec 2009 14:31 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. Scott -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: David Fetter on 15 Dec 2009 14:49 On Tue, Dec 15, 2009 at 11:31:05AM -0800, Scott Bailey wrote: > Jeff Davis wrote: > >On Tue, 2009-12-15 at 10:19 -0500, Tom Lane wrote: > > Would it be OK if we handled float timestamp ranges as continuous > and int64 timestamps discrete? That sounds like a recipe for disaster. Whatever timestamp ranges are, float and int64 should be treated the same way so as not to get "surprises" due to implementation details. > 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. [] makes certain operations--namely the important ones in calendaring--impossible, or at least incredibly kludgy, to do. I think we ought to leave openness at each end up to the user, independent of the underlying implementation details. FWIW, I think it would be a good idea to treat timestamps as continuous in all cases. Cheers, David. -- David Fetter <david(a)fetter.org> http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fetter(a)gmail.com iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Tom Lane on 15 Dec 2009 16:16
David Fetter <david(a)fetter.org> writes: > On Tue, Dec 15, 2009 at 11:31:05AM -0800, Scott Bailey wrote: >> 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. > [] makes certain operations--namely the important ones in > calendaring--impossible, or at least incredibly kludgy, to do. I > think we ought to leave openness at each end up to the user, > independent of the underlying implementation details. Yes. A range implementation that couldn't support all four cases of [], [), (], () would be seriously crippled IMO. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |