| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | pgsql(at)mohawksoft(dot)com |
| Cc: | "Neil Conway" <neilc(at)samurai(dot)com>, "Pailloncy Jean-Gerard" <jg(at)rilk(dot)com>, "Hannu Krosing" <hannu(at)tm(dot)ee>, "Pg Hackers" <pgsql-hackers(at)postgresql(dot)org>, "Victor Y(dot) Yegorov" <viy(at)mits(dot)lv> |
| Subject: | Re: bitmap AM design |
| Date: | 2005-03-04 15:28:24 |
| Message-ID: | 27526.1109950104@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
pgsql(at)mohawksoft(dot)com writes:
> Anyway, IMHO, hash indexes would be dramatically improved if you could
> specify your own hashing function
That's called a custom operator class.
> and declare initial table size.
It would be interesting to see if setting up the hashtable with about
the right number of buckets initially would make CREATE INDEX enough
faster to be a win ... but that doesn't mean I want to make the user
deal with it. We could probably hack hashbuild() to estimate the
size of the parent table using the same code that the planner is now
using (ie, actual size in pages times a possibly-dead-reckoning rows
per page estimate).
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2005-03-04 15:42:08 | Re: Solving hash table overrun problems |
| Previous Message | Bostjan Potocnik | 2005-03-04 15:09:52 | db cluster ? |