Re: GiST: interpretation of NaN from penalty function

From: Andrew Borodin <borodin(at)octonica(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Oleg Bartunov <obartunov(at)gmail(dot)com>, Teodor Sigaev <teodor(at)postgrespro(dot)ru>, Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru>, Greg S <stark(at)mit(dot)edu>
Subject: Re: GiST: interpretation of NaN from penalty function
Date: 2016-09-15 18:14:18
Message-ID: CAJEAwVEnTeg+yyoAQWZyYTTy0h3MLt77pjoVRwkkMuDKOi0LoA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> Certainly, "NaN means infinity", as your patch proposes, has no more basis to it than "NaN means zero".
You are absolutley right. Now I see that best interpretation is "NaN
means NaN". Seems like we need only drop a check. Nodes with NaN
penalties will be considered even worser than those with infinity
penalty.
Penalty calculation is CPU performance critical, it is called for
every tuple on page along insertion path. Ommiting this check will
speed this up...a tiny bit.
> If the penalty function doesn't like that interpretation, it shouldn't return NaN.
It may return NaN accidentally. If NaN will pass through union()
function then index will be poisoned.
That's not a good contract to remember for extension developer.

Regards, Andrey Borodin.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2016-09-15 18:32:32 Re: RLS related docs
Previous Message Tom Lane 2016-09-15 18:11:11 Re: Use pread and pwrite instead of lseek + write and read