Re: [HACKERS] Bizarre coding in _bt_binsrch - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [HACKERS] Bizarre coding in _bt_binsrch
Date
Msg-id 18743.943927632@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] Bizarre coding in _bt_binsrch  (Bruce Momjian <pgman@candle.pha.pa.us>)
Responses Re: [HACKERS] Bizarre coding in _bt_binsrch  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-hackers
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Tom, I assume you have dealt with this, right?

>> I have been puzzling out the coding in _bt_binsrch() in
>> backend/access/nbtree/nbtsearch.c, with an eye to speeding it up for
>> the many-equal-keys case.

I tweaked the code to go faster in the equal-keys case, but Vadim later
pointed out that what we *really* should do is force the algorithms to
never consider two index keys equal (eg, by including the heap tuple id
as the last part of the comparison key).  See his pgsql-hackers message
dated 06 Jun 1999 21:32:36 +0800.  Getting the full benefit would
require ripping out the BTP_CHAIN logic and doing some other major
surgery, so I don't feel like I know the btree code well enough to
tackle it.  It should be on the TODO list though:

* Include heap CTID in btree index keys, remove equal-key cruft from btree
        regards, tom lane


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: [HACKERS] sort on huge table
Next
From: Tom Lane
Date:
Subject: Re: [HACKERS] destroydb doesn't close connection with client (httpd <-> pg)