From: | admin <admin(at)wtbwts(dot)com> |
---|---|
To: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: [GENERAL] hash taboo? |
Date: | 1999-12-17 22:54:22 |
Message-ID: | Pine.BSF.4.10.9912172250001.8458-100000@server.b0x.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Culberson, Philip | 1999-12-17 23:03:14 | RE: [GENERAL] How to get timestamped pgsql logging? |
Previous Message | admin | 1999-12-17 22:41:58 | Re: [GENERAL] hash taboo? |