Skip site navigation (1) Skip section navigation (2)

Re: [PERFORM] BUG #2737: hash indexing large tablefails,while btree of same index works

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Simon Riggs" <simon(at)2ndquadrant(dot)com>
Cc: "Balazs Nagy" <bnagy(at)thenewpush(dot)com>, pgsql-bugs(at)postgresql(dot)org, pgsql-performance(at)postgresql(dot)org
Subject: Re: [PERFORM] BUG #2737: hash indexing large tablefails,while btree of same index works
Date: 2006-11-17 15:08:47
Message-ID: 13525.1163776127@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-bugspgsql-performance
"Simon Riggs" <simon(at)2ndquadrant(dot)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

In response to

pgsql-performance by date

Next:From: Julius.StroffekDate: 2006-11-17 15:36:18
Subject: Re: [PERFORM] BUG #2737: hash indexing large tablefails,while
Previous:From: Simon RiggsDate: 2006-11-17 14:38:12
Subject: Re: [PERFORM] BUG #2737: hash indexing largetablefails,while btree of same index works

pgsql-bugs by date

Next:From: Julius.StroffekDate: 2006-11-17 15:36:18
Subject: Re: [PERFORM] BUG #2737: hash indexing large tablefails,while
Previous:From: Simon RiggsDate: 2006-11-17 14:38:12
Subject: Re: [PERFORM] BUG #2737: hash indexing largetablefails,while btree of same index works

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group