Re: b-tree index search algorithms

Am 17.07.12 05:21, schrieb Tom Lane:
> Samuel Vogel <s@muel-vogel.de> writes:
>> I'm currently on a university research project if performance could be
>> increased by substituting different inter-node search algorithms instead
>> of the currently used binary search.
> Hm, what have you got in mind exactly?

At first I will try a simple interpolation search, but problems start 
there since I need to have a numerical representation of the index keys 
(or map them to one) to do the interpolation.

>> But I'm having troubles understanding how the general b-tree
>> implementation (nbtree.h) is used to represent for example a simple
>> primary key on an integer column. I've debug printed the
>> 'scankey->sk_argument' and all attributes of the index tuples on the
>> pages being traversed (simply ran 'DatumGetInt32' on both) but I never
>> see one of the integers actually appearing in my table being logged when
>> I do a select.
> Not clear what you did wrong from this amount of detail, but integer
> keys ought to be pretty obvious at the debugger level.

Okay, to be more specific: Printing 
'DatumGetInt32(scankey->sk_argument)' in '_bt_compare' never shows me 50 
when I execute this query: SELECT * FROM simpletest WHERE id = 50;

>> This is why I assume that all column values are hashed before they are
>> pushed into the b-tree,
> PG's b-trees do not hash anything.  If you're not seeing interpretable
> key values then you're doing something wrong in your inspection
> methodology.

Okay, how are indexes on char/text columns handled then? Are they hashed 
before being put into the b-tree or is my assumption correct, that in 
that case the Datum is only a link to where the actual data is stored 
and only 'scankey->sk_func' knows how to make use of it (compare it).
In that case it would be extremly hard to get to a numeric 
representation which can be used for the interpolation.

Regards,
Samuel Vogel