On Thu, Mar 06, 2014 at 06:14:21PM -0500, Robert Haas wrote:
> On Thu, Mar 6, 2014 at 3:44 PM, Jeff Janes <jeff.janes@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.
>
It would be useful to have a storage parameter for the target size of
the index, even if it is not exact, to use in the initial index build
to avoid the flurry of i/o caused by bucket splits as the index grows.
Regards,
Ken