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.
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 |