On Sat, Oct 23, 2004 at 23:36:05 -0400,
Tom Lane <[EMAIL PROTECTED]> wrote:
>
> We don't have to have this particular sorting decision, we just have
> to have *some* unique sorting order. In particular, if we want to say
> that two interval values are not equal, we have to be able to say which
> one is less. For instance, "compare the months first and only if equal
> compare the seconds" would work fine from the point of view of btree.
> It's just that that leads to a sort order that users will probably not
> like very much.
One way to do comparisons is to use a mapping f(m,s) => R and compare
(m1,s1) and (m2,s2) by comparing f(m1,s1) and f(m2,s2) and break ties
by comparing say m1 and m2. This will work as long as f(m,s1) = f(m,s2)
implies s1 = s2. It will probably be desirable to use a subset of these
mappings where f(m,s) = g(m) + h(s). In fact the current system uses
this with g(m) = 30*24*60*60*m and h(s) = s (but without the tiebreak
that compares m values). Because of the way intervals work, I think
you want to use an ordering generated like that you want to use
something of the form f(m,s) = C1*m + C2*s. I also think that treating
a month as 30 days and having round numbers is better than using
something like 1/12 a solar year in seconds. So I think the best plan
is to do things as they are now, except for adding a tie breaker just
using months or seconds for when both intervals give the same number of
seconds when treating months as 30 days, but have a different number of
months.
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
