Re: [BUGS] BUG #2737: hash indexing large tablefails,while btree of same index works - Mailing list pgsql-performance

From Tom Lane
Subject Re: [BUGS] BUG #2737: hash indexing large tablefails,while btree of same index works
Date
Msg-id 13525.1163776127@sss.pgh.pa.us
Whole thread Raw
In response to Re: [BUGS] BUG #2737: hash indexing large tablefails,while btree of same index works  ("Simon Riggs" <simon@2ndquadrant.com>)
List pgsql-performance
"Simon Riggs" <simon@2ndquadrant.com> writes:
> Do we think there is hope of improving hash indexes?

Sure.  They lack WAL support, which is just a small matter of
programming.  And no one has ever spent any time on performance
optimization for them, but it certainly seems like there ought to be
scope for improvement.  I don't we should toss them unless it's been
proven that their theoretical performance advantages can't be realized
for some reason.  (This is unlike the situation for rtree, because with
rtree there was no reason to expect that rtree could dominate gist along
any axis.)

> If there is hope, is there a specific place to look?

I recall some speculation that using bucket size == page size might
be a bad choice, because it leads to mostly-empty buckets for typical
key sizes and fill factors.  Using a configurable bucket size could
help a lot.

            regards, tom lane

pgsql-performance by date:

Previous
From: "Simon Riggs"
Date:
Subject: Re: [BUGS] BUG #2737: hash indexing largetablefails,while btree of same index works
Next
From: "Julius.Stroffek"
Date:
Subject: Re: [BUGS] BUG #2737: hash indexing large tablefails,while