Re: [HACKERS] Bizarre coding in _bt_binsrch

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: [HACKERS] Bizarre coding in _bt_binsrch
Date: 1999-11-30 02:07:12
Message-ID: 18743.943927632@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)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

Responses

Browse pgsql-hackers by date

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