Re: [HACKERS] Current int & float overflow checking is slow.

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: [HACKERS] Current int & float overflow checking is slow.
Дата
Msg-id 20171025055349.acz4fqaxk7scm5ht@alap3.anarazel.de
обсуждение исходный текст
Ответ на Re: [HACKERS] Current int & float overflow checking is slow.  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
On 2017-10-25 07:33:46 +0200, Robert Haas wrote:
> On Tue, Oct 24, 2017 at 9:28 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > I don't like changing well-defined, user-visible query behavior for
> > no other reason than a performance gain (of a size that hasn't even
> > been shown to be interesting, btw).  Will we change it back in another
> > ten years if the performance tradeoff changes?

That part of the argument seems unconvincing. It's not like the overflow
check is likely to ever have been beneficial performancewise, nor is it
remotely likely for that to ever be the case.


> > Also, if I recall the old discussion properly, one concern was getting
> > uniform behavior across different platforms.  I'm worried that if we do
> > what Andres suggests, we'll get behavior that is not only different but
> > platform-specific.  Now, to the extent that you believe that every modern
> > platform implements edge-case IEEE float behavior the same way, that worry
> > may be obsolete.  But I don't think I believe that.
> 
> Yeah, those are reasonable concerns.

I agree. I'm not really sure what the right way is here. I do however
think it's worth discussing what ways to address the performance penalty
due to the overflow checks, and one obvious way to do so is not to play.

It'd be interesting to write the overflow checking addition in x86
inline asm, and see how much better that gets - just so we know the
maximum we can reach with that. The problem with the C99 stuff seems to
be the external function calls.  With either, one problem would be that
we'd have to reset the overflow register before doing math, which isn't
free either - otherwise some external function could have left it set to
on.

Greetings,

Andres Freund


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Peter Geoghegan
Дата:
Сообщение: Re: [HACKERS] unique index violation after pg_upgrade to PG10
Следующее
От: Thomas Munro
Дата:
Сообщение: Re: [HACKERS] Parallel Hash take II