Re: BUG #14210: filter by "=" constraint doesn't work when hash index is present on a column
От | Tom Lane |
---|---|
Тема | Re: BUG #14210: filter by "=" constraint doesn't work when hash index is present on a column |
Дата | |
Msg-id | 2502.1466805945@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: BUG #14210: filter by "=" constraint doesn't work when hash index is present on a column (Peter Geoghegan <pg@heroku.com>) |
Ответы |
Re: BUG #14210: filter by "=" constraint doesn't work when
hash index is present on a column
|
Список | pgsql-bugs |
Peter Geoghegan <pg@heroku.com> writes: > On Fri, Jun 24, 2016 at 2:20 PM, Tom Lane <tgl@sss.pgh.pa.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
В списке pgsql-bugs по дате отправления: