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.ja...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers