Re: b-tree index search algorithms

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

Am 17.07.12 19:38, schrieb Tom Lane:
> btree knows nothing about the datatypes it's working on except that
> they have comparison functions. Converting the values to some sort of
> numeric scale that you can interpolate on seems logically dubious and
> fraught with practical difficulties. Now, we do have some code in
> selfuncs.c that tries to do that, for some data types, but it's only
> for planner estimation purposes, and we don't rely very heavily on its
> results even in that context. Depending on it to be right for search
> purposes sounds pretty scary.

'convert_string_to_scalar' and others look interesting in selfuncs.c,
thanks for the pointer!

>> Okay, how are indexes on char/text columns handled then?
> The datum values will be pointers to strings.

I can simply dereference it and read all bytes until a null-byte appears
(depending on the collation and that I know that it actually is a string)?

> The btree code is (or reasonably can be) aware that such values are
> pass-by-reference, and how to get to the bits. But the comparison
> semantics of two different values are not something it knows about
> except by asking the comparison function. This can be quite a
> nontrivial matter even for text, since we follow strcoll() comparison
> rules. regards, tom lane

How would the b-tree know exactly that a value is only a reference? And
even in that case you say that it could get the bits, but make no use of
it, since it does not know what they represent, right?

Regards,
Samuel

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2012-07-18 21:49:37 CHECK NO INHERIT syntax
Previous Message Simon Riggs 2012-07-18 21:45:08 Re: Checkpointer split has broken things dramatically (was Re: DELETE vs TRUNCATE explanation)