On Thu, Mar 6, 2014 at 11:14 PM, Robert Haas <robertmhaas@gmail.com> wrote:
>> I've been tempted to implement a new type of hash index that allows both WAL
>> and high concurrency, simply by disallowing bucket splits. At the index
>> creation time you use a storage parameter to specify the number of buckets,
>> and that is that. If you mis-planned, build a new index with more buckets,
>> possibly concurrently, and drop the too-small one.
>
> Yeah, we could certainly do something like that. It sort of sucks,
> though. I mean, it's probably pretty easy to know that starting with
> the default 2 buckets is not going to be enough; most people will at
> least be smart enough to start with, say, 1024. But are you going to
> know whether you need 32768 or 1048576 or 33554432? A lot of people
> won't, and we have more than enough reasons for performance to degrade
> over time as it is.
The other thought I had was that you can do things lazily in vacuum.
So when you probe you need to check multiple pages until vacuum comes
along and rehashes everything.
--
greg