Re: b-tree index search algorithms

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Samuel Vogel <s(at)muel-vogel(dot)de>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: b-tree index search algorithms
Date: 2012-07-17 03:21:47
Message-ID: 13121.1342495307@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Samuel Vogel <s(at)muel-vogel(dot)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?

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

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

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2012-07-17 03:37:59 Re: CompactCheckpointerRequestQueue versus pad bytes
Previous Message Tom Lane 2012-07-17 02:15:35 Re: BUG #6733: All Tables Empty After pg_upgrade (PG 9.2.0 beta 2)