Re: GiST penalty functions [PoC] - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: GiST penalty functions [PoC]
Date
Msg-id 753b8caf-ebe1-fa58-dfa3-ac5b74fb7f2e@iki.fi
Whole thread Raw
In response to Re: GiST penalty functions [PoC]  (Andrew Borodin <borodin@octonica.com>)
Responses Re: GiST penalty functions [PoC]  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On 09/07/2016 09:20 PM, Andrew Borodin wrote:
> Well, arithmetics is too fragile.
>
> This version of float packing with arithmetical packaging
> static float
> pack_float(float actualValue, int realm)
> {
> double max,min;
> max = FLT_MAX / ( 8 >> realm );
> min = FLT_MAX / ( 16 >> realm );
> if( realm == 0 )
> min = 0;
> /* squeeze the actual value between min and max */
> return ( min + (actualValue * ( max - min ) / FLT_MAX));
> }
> Inserts are the same as of bithacked pack_float, but selects are 5 times slower.
> When we are trying to pack value linearly into range we loose too much bits.

That's why I suggested scaling it by the new value's volume and/or 
edge-sum. I was hoping that the old and new values are roughly of the 
same magnitude, so that it would work out. I guess not.

But we could probably something like the above too, if we use 
logarithmic or exponential, rather than linear, packing. Something like:

static float
pack_float(float actualValue, int realm)
{  double  val;
  val = sqrt(sqrt(actualValue));
  if (realm == 0)    return actualvalue;  if (realm == 1)    return actualValue * sqrt(sqrt(FLT_MAX));  if (realm == 2)
  return actualValue * sqrt(FLT_MAX);
 
}

Unfortunately, sqrt(x) isn't very cheap.

- Heikki




pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: Is tuplesort_heap_siftup() a misnomer?
Next
From: Heikki Linnakangas
Date:
Subject: Re: Parallel tuplesort (for parallel B-Tree index creation)