Skip site navigation (1) Skip section navigation (2)

Re: bitmap AM design

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: (view raw, whole thread or download thread mbox)
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

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.

In response to

pgsql-hackers by date

Next:From: Andrew DunstanDate: 2005-03-04 18:11:55
Subject: buildfarm issues
Previous:From: Bruno Wolff IIIDate: 2005-03-04 16:22:01
Subject: Re: Solving hash table overrun problems

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group