Re: GiST penalty functions [PoC]

From: Михаил Бахтерев <mob(at)k(dot)imm(dot)uran(dot)ru>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, amborodin(at)acm(dot)org, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru>, Михаил Бахтерев <mike(dot)bakhterev(at)gmail(dot)com>
Subject: Re: GiST penalty functions [PoC]
Date: 2016-09-08 06:39:31
Message-ID: 20160908063931.GA17347@kite
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Excuse me for intervention.

It depends. For instance, i run PostgreSQL on the modern MIPS CPU, which
does not have sqrt support.

But you are right, it is supported in most cases. And if execution speed
of this very fuction is of concern, sqrtf(x) should be used instead of

Despite this, Andrew's solution gives more accurate representation of
values. And as far as i understand, this improves overall performance by
decreasing the overall amount of instructions, which must be executed.

It is possible to speed up Andrew's implementation and get rid of
warnings by using bit-masks and unions. Something like:

union {
float f;
struct {
unsigned int mantissa:23, exponent:8, sign:1;
} bits;

I am sorry, i have no time to check this. But it is common wisdom to
avoid pointer-based memory accesses in high-performance code, as they
create a lot of false write-to-read dependencies.

- Mikhail, respectfully

On Wed, Sep 07, 2016 at 05:58:42PM -0400, Tom Lane wrote:
> Heikki Linnakangas <hlinnaka(at)iki(dot)fi> writes:
> > Unfortunately, sqrt(x) isn't very cheap.
> You'd be surprised: sqrt is built-in on most modern hardware. On my
> three-year-old workstation, sqrt(x) seems to take about 2.6ns. For
> comparison, the pack_float version posted in
> <CAJEAwVGdb92E-XKfMLN3cxM2BWbbA3rrffzDzg8Ki1H5iQEk2Q(at)mail(dot)gmail(dot)com>
> takes 3.9ns (and draws multiple compiler warnings, too).
> regards, tom lane

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2016-09-08 06:43:06 Re: Bug in two-phase transaction recovery
Previous Message Kyotaro HORIGUCHI 2016-09-08 06:35:46 Re: Supporting SJIS as a database encoding