Andres Freund <and...@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
