On Thu, Mar 6, 2014 at 3:44 PM, Jeff Janes <jeff.janes@gmail.com> wrote:
> On Thu, Mar 6, 2014 at 11:34 AM, Robert Haas <robertmhaas@gmail.com> wrote:
>> Putting the split-in-progress flag in the new bucket's primary page
>> makes a lot of sense. I don't have any problem with dumping the rest
>> of it for a first cut if we have a different long-term plan for how to
>> improve concurrency, but I don't see much point in going to a lot of
>> work to implement a system for WAL logging if we're going to end up
>> having to afterwards throw it out and start from scratch to get rid of
>> the heavyweight locks - and it's not obvious to me how what you have
>> here could be extended to do that.
>
> +1 I don't think we have to improve concurrency at the same time as WAL
> logging, but we at least have to implement WAL logging in a way that doesn't
> foreclose future improvements to concurrency.
>
> 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.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
