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 | 12194.1466724741@sss.pgh.pa.us обсуждение исходный текст |
| Ответ на | Re: BUG #14210: filter by "=" constraint doesn't work when hash index is present on a column (Tom Lane <tgl@sss.pgh.pa.us>) |
| Список | pgsql-bugs |
I wrote:
> So the answer is that this got broken by commit 9f03ca915196dfc8,
> which appears to have imagined that _hash_form_tuple() is just an
> alias for index_form_tuple(). But it ain't. As a result, construction
> of hash indexes larger than shared_buffers is broken in 9.5 and up:
BTW, an easy way to prove that the _h_spool code path is broken is to
do this:
diff --git a/src/backend/access/hash/hash.c b/src/backend/access/hash/hash.c
index 49a6c81..162cb63 100644
--- a/src/backend/access/hash/hash.c
+++ b/src/backend/access/hash/hash.c
@@ -125,7 +125,7 @@ hashbuild(Relation heap, Relation index, IndexInfo *indexInfo)
* NOTE: this test will need adjustment if a bucket is ever different from
* one page.
*/
- if (num_buckets >= (uint32) NBuffers)
+ if (1)
buildstate.spool = _h_spoolinit(heap, index, num_buckets);
else
buildstate.spool = NULL;
and then run the regression tests. I'm thinking it would be a good
idea to provide some less-painful way to force that code path to be
taken for testing purposes.
regards, tom lane
В списке pgsql-bugs по дате отправления: