| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | Simon Riggs <simon(at)2ndquadrant(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, isaac(dot)morland(at)gmail(dot)com, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: 'infinity'::Interval should be added |
| Date: | 2018-12-15 20:02:37 |
| Message-ID: | 26567.1544904157@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Andres Freund <andres(at)anarazel(dot)de> writes:
> On 2018-12-15 14:43:49 -0500, Tom Lane wrote:
>> Note that timestamp_lt etc don't actually need any special case for
>> infinity, and we could hope that the infinity representation for interval
>> makes it possible to likewise not special-case it in interval comparisons.
>> But I think it's silly to argue that infinity handling is a significant
>> fraction of something like timestamp_pl_interval or timestamp_part.
> I'm inclined to agree that if done carefully the overhead here is
> probably acceptable.
Backing up to look at the actual code ... if the infinity representation
is the max or min value in each of the three fields, then the conversion
done by interval_cmp_value would yield an int128 value that's certainly
greater than or less than any other interval value, and I don't think it
can overflow, so there's no need to add any code to the comparison cases.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Vijaykumar Jain | 2018-12-15 20:13:56 | simple query on why a merge join plan got selected |
| Previous Message | Andres Freund | 2018-12-15 19:48:55 | Re: 'infinity'::Interval should be added |