I wrote:
> But exercising a non-default code path in hash index build is something we
> only need in one place in the tests, and at least in my judgment there is
> a possibility for platform-specific behavior. So I think some way of
> turning it on dynamically, and then adding that as a standard test case,
> would be a considerable improvement. I just don't quite want to go to the
> effort of inventing a GUC or reloption. Is there some intermediate
> answer?
A small-footprint answer that just occurred to me is to redefine the
threshold as being, not NBuffers, but maintenance_work_mem. Then a
reasonably-sized test case could be made by reducing that to its minimum
allowed value. This seems like it'd be fairly unsurprising for users
since there's lots of precedent for maintenance_work_mem affecting the
behavior of CREATE INDEX.
If maintenance_work_mem exceeds shared_buffers then you'd get a certain
amount of thrashing between shared buffers and kernel disk cache, but it
wouldn't be really awful unless maintenance_work_mem exceeded available
RAM, which would be a certifiably Bad Idea anyway. I guess we could
forestall the buffer-thrashing scenario and preserve testability by
setting the sort threshold to min(NBuffers, maintenance_work_mem).
regards, tom lane
