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

From Tom Lane
Subject Re: BUG #14210: filter by "=" constraint doesn't work when hash index is present on a column
Date
Msg-id 12194.1466724741@sss.pgh.pa.us
Whole thread Raw
In response to Re: BUG #14210: filter by "=" constraint doesn't work when hash index is present on a column  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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 by date:

Previous
From: Tom Lane
Date:
Subject: Re: BUG #14210: filter by "=" constraint doesn't work when hash index is present on a column
Next
From: Daniel Newman
Date:
Subject: Re: BUG #14210: filter by "=" constraint doesn't work when hash index is present on a column