From: | pgsql(at)mohawksoft(dot)com |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
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 17:55:04 |
Message-ID: | 16544.24.91.171.78.1109958904.squirrel@mail.mohawksoft.com |
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.
Would I also be able to query the bucket size and all that?
>
>> 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).
>
I know a linear hash is different than a classic simple hash table, but a
classic simple hash table has some great advantages at the expense of disk
space. IMHO being able to use the hash index in a way that is more of the
classic theoretical hash table and use the linear behavor if the table
grows beyond initial estimates I think would be a big win. It could
actually get to a 1:1 operation data retrieval on properly estimated
tables.
Estimations are a great idea, something like first prime after 2*NROWS
(with a GUC limit, I guess) would probably make hash indexes the fastest
most disk hogging index around.
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2005-03-04 18:11:55 | buildfarm issues |
Previous Message | Bruno Wolff III | 2005-03-04 16:22:01 | Re: Solving hash table overrun problems |