Skip site navigation (1)
Skip section navigation (2)
Peripheral Links
Header And Logo
|
Site Navigation
Re: [BUGS] BUG #2737: hash indexing large table fails,while btree of same index works
- From: "Simon Riggs" <simon(at)2ndquadrant(dot)com>
- To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
- Cc: "Balazs Nagy" <bnagy(at)thenewpush(dot)com>, <pgsql-bugs(at)postgresql(dot)org>, <pgsql-performance(at)postgresql(dot)org>
- Subject: Re: [BUGS] BUG #2737: hash indexing large table fails,while btree of same index works
- Date: Sat, 11 Nov 2006 08:17:54 +0000
- Message-id: <1163233075(dot)3634(dot)944(dot)camel(at)silverbirch(dot)site>
On Fri, 2006-11-10 at 18:55 -0500, Tom Lane wrote: > [ cc'ing to pgsql-performance because of performance issue for hash indexes ] > > "Balazs Nagy" <bnagy(at)thenewpush(dot)com> writes: > > Database table size: ~60 million rows > > Field to index: varchar 127 > > > CREATE INDEX ... USING hash ... I'd be interested in a performance test that shows this is the best way to index a table though, especially for such a large column. No wonder there is an 8GB index. > One thought that comes to mind is to require hash to do an smgrextend() > addressing the last block it intends to use whenever it allocates a new > batch of blocks, whereupon md.c could adopt a saner API: allow > smgrextend but not other calls to address blocks beyond the current EOF. > Thoughts? Yes, do it. -- Simon Riggs EnterpriseDB http://www.enterprisedb.com
- Follow-Ups:
- References:
- Prev by Date: Re: [BUGS] BUG #2737: hash indexing large table fails, while btree of same index works
- Next by Date: Re: Lying drives [Was: Re: Which OS provides the _fastest_ PostgreSQL performance?]
- Previous by thread: Re: [BUGS] BUG #2737: hash indexing large table fails, while btree of same index works
- Next by thread: Re: [BUGS] BUG #2737: hash indexing large table fails,while btree of same index works
- Indexes: