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
