Re: BUG #14210: filter by "=" constraint doesn't work when hash index is present on a column
От | Peter Geoghegan |
---|---|
Тема | Re: BUG #14210: filter by "=" constraint doesn't work when hash index is present on a column |
Дата | |
Msg-id | CAM3SWZRCjnttFcXUeN0fuWSd3dXPmP7B4i_pu8C9kQs8ZUoThg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: BUG #14210: filter by "=" constraint doesn't work when hash index is present on a column (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: BUG #14210: filter by "=" constraint doesn't work when hash index is present on a column
|
Список | pgsql-bugs |
On Sat, Jun 25, 2016 at 8:32 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> I think that this is an argument against further proliferation of >> #define's for this kind of thing, not an argument against adding a way >> to force tuplesort based hash index builds. > > So ... what's your point? This statement doesn't seem to lead to a > conclusion in favor of either of the alternatives I mentioned. I'm in favor of just adding a debug option. We should introduce a more general idea of a #define that enables a variety of debugging options, because it's silly to have to worry about buildfarm coverage each and every time this crops up. I'm not entirely sure what level that should be scoped at. The status quo is impractical. Incidentally, did you see to it that there is buildfarm coverage for RAW_EXPRESSION_COVERAGE_TEST? -- Peter Geoghegan
В списке pgsql-bugs по дате отправления: