From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Peter Geoghegan <pg(at)heroku(dot)com> |
Cc: | Daniel Newman <dtnewman(at)gmail(dot)com>, danielnewman(at)umich(dot)edu, Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-bugs <pgsql-bugs(at)postgresql(dot)org> |
Subject: | Re: BUG #14210: filter by "=" constraint doesn't work when hash index is present on a column |
Date: | 2016-06-27 15:21:09 |
Message-ID: | 1681.1467040869@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Geoghegan | 2016-06-27 18:06:01 | Re: BUG #14210: filter by "=" constraint doesn't work when hash index is present on a column |
Previous Message | Tom Lane | 2016-06-27 14:54:39 | Re: BUG #14210: filter by "=" constraint doesn't work when hash index is present on a column |