Re: BUG #14210: filter by "=" constraint doesn't work when hash index is present on a column

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-24 22:05:45
Message-ID: 2502.1466805945@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Peter Geoghegan <pg(at)heroku(dot)com> writes:
> On Fri, Jun 24, 2016 at 2:20 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> I agree that we need to do something, but I'm not very clear on what
>> the something is. I considered inventing a debug #define that would
>> reduce the _h_spool threshold to the minimum workable amount (2, looks
>> like), but I'm not sure how much that will help. What did you have
>> in mind?

> I think we should do that. Why do you say that you're not sure how
> much it will help?

Well, it won't run automatically --- unless someone spins up a buildfarm
machine that adds that symbol to CPPFLAGS, and even then we'd only have
coverage on one platform.

However, the next step up would be to invent an index storage parameter or
some such to force the decision, letting the standard regression tests
include a reasonably-cheap case that would exercise _h_spool. But that
seems like rather a large amount of work compared to the likely benefits.

regards, tom lane

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Peter Geoghegan 2016-06-24 22:07:46 Re: BUG #14210: filter by "=" constraint doesn't work when hash index is present on a column
Previous Message Peter Geoghegan 2016-06-24 21:56:54 Re: BUG #14210: filter by "=" constraint doesn't work when hash index is present on a column