Re: Why hash indexes suck

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: Zeugswetter Andreas SB SD <ZeugswetterA(at)spardat(dot)at>, Jeff Davis <jdavis-pgsql(at)empires(dot)org>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Why hash indexes suck
Date: 2004-06-10 05:12:34
Message-ID: 19904.1086844354@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 Lane wrote:
>> [blink] This seems to miss out on the actual point of the thread (hash
>> bucket size shouldn't be a disk page) in favor of an entirely
>> unsupported sub-suggestion.

> Yes, I was unsure of the text myself. I have changed it to:
> * Allow hash buckets to fill disk pages, rather than being
> sparse

OK, though maybe "pack hash index buckets onto disk pages more
efficiently" would be clearer.

> If we sorted the keys, how do we insert new entries efficiently?

That is why I called it "unsupported". I'm not clear what would happen
in buckets that overflow onto multiple pages --- do we try to maintain
ordering across all the pages, or just within a page, or what? How much
does this buy us versus what it costs to maintain? Maybe there's a win
there but I think it's pretty speculative ...

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2004-06-10 05:14:01 Re: [PATCHES] serverlog function (log_destination file)
Previous Message Bruce Momjian 2004-06-10 04:13:19 Re: thread safety tests