Re: [GENERAL] hash taboo?
От | admin |
---|---|
Тема | Re: [GENERAL] hash taboo? |
Дата | |
Msg-id | Pine.BSF.4.10.9912172250001.8458-100000@server.b0x.com обсуждение исходный текст |
Ответ на | Re: [GENERAL] hash taboo? (Bruce Momjian <pgman@candle.pha.pa.us>) |
Ответы |
Re: [GENERAL] hash taboo?
|
Список | pgsql-general |
Excellent point, your last comment gives me a tangible incentive for using hash instead of btree. Since I don't need to use other operators than '=', there is really no need to spend extra time creating a btree while all I need is a hash table. In the end, both are as fast for searching, but I gain some additional speed for inserting and removing entries. > > My results were exactly the same for btree and hash, even when vacumming > > between each index creation. Here's my query: > > SELECT * FROM prod_base WHERE mid='2'; > > > > Here's my result: > > Index Scan using prod_mid_idx on prod_base (cost=2.05 rows=2 width=120) > > > > My database is perhaps not big enough to run some relevant tests, so > > please let me know if there's another way I could get a better idea of the > > resources used for using each searching method. > > You have to look at index creation speed and index access speed. > > Not sure which one wins in each category. Also, index modification > speed may be important. Thanks again, Marc
В списке pgsql-general по дате отправления: