Re: [BUGS] BUG #2737: hash indexing large table fails,while btree of same index works
| От | Simon Riggs |
|---|---|
| Тема | Re: [BUGS] BUG #2737: hash indexing large table fails,while btree of same index works |
| Дата | |
| Msg-id | 1163233075.3634.944.camel@silverbirch.site обсуждение исходный текст |
| Ответ на | Re: [BUGS] BUG #2737: hash indexing large table fails, while btree of same index works (Tom Lane <tgl@sss.pgh.pa.us>) |
| Ответы |
Re: [BUGS] BUG #2737: hash indexing large table fails,while btree of same index works
|
| Список | pgsql-performance |
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@thenewpush.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
В списке pgsql-performance по дате отправления: