Re: 'infinity'::Interval should be added

Andres Freund <andres@anarazel.de> writes:
> On 2018-12-15 09:44:50 -0500, Tom Lane wrote:
>> Yes.  The performance argument has some merit for cases like int4 and
>> float8, where the "useful work" might be as small as one machine
>> instruction.  But timestamp and interval operations are, for the most
>> part, pretty darn expensive.  I doubt that adding special cases to
>> them for infinity is going to move the needle noticeably.  (And as
>> for JIT, I sincerely hope that the compiler is not dumb enough to try
>> to in-line those functions.)

> Something like interval_pl is cheap enough to inline (without inlinining
> palloc, and elog.c infrastructure), even though there's repeated
> ereports() checks with different parameters / line numbers [1]. Boils
> down to ~70 instructions, which allows inlining. But I suspect more
> important than those, are operations like timestamp_lt etc, which
> currently are ~8 instructions.  It's pretty common to have a
> timestamp_lt or such in sequential scans, so that's good too.

I said "for the most part", I did not say that every single function
on those types is expensive.

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.

            regards, tom lane