Re: GiST penalty functions [PoC]

Поиск
Список
Период
Сортировка
От Heikki Linnakangas
Тема Re: GiST penalty functions [PoC]
Дата
Msg-id 753b8caf-ebe1-fa58-dfa3-ac5b74fb7f2e@iki.fi
обсуждение исходный текст
Ответ на Re: GiST penalty functions [PoC]  (Andrew Borodin <borodin@octonica.com>)
Ответы Re: GiST penalty functions [PoC]  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Peter Geoghegan
Дата:
Сообщение: Re: Is tuplesort_heap_siftup() a misnomer?
Следующее
От: Heikki Linnakangas
Дата:
Сообщение: Re: Parallel tuplesort (for parallel B-Tree index creation)