On Mon, Sep 16, 2019 at 7:23 AM Paul A Jungwirth
<p...@illuminatedcomputing.com> wrote:
>
> On Sat, Sep 14, 2019 at 5:13 AM Amit Kapila <amit.kapil...@gmail.com> wrote:
> > In general, the hash_range is covered by some of the existing test,
> > but I don't which test. See the code coverage report here:
> > https://coverage.postgresql.org/src/backend/utils/adt/rangetypes.c.gcov.html
>
> Thanks! I did some experimenting, and the current test code *only*
> calls `hash_range_internal` when we force it like this:
>
I don't see this function on the master branch. Is this function name
correct? Are you looking at some different branch?
> set enable_nestloop=f;
> set enable_hashjoin=t;
> set enable_mergejoin=f;
> select * from numrange_test natural join numrange_test2 order by nr;
>
> But if I create that index as a hash index instead, we also call it
> for these inserts and selects (except for the empty ranges):
>
> create table numrange_test2(nr numrange);
> create index numrange_test2_hash_idx on numrange_test2 (nr);
>
> INSERT INTO numrange_test2 VALUES('[, 5)');
> INSERT INTO numrange_test2 VALUES(numrange(1.1, 2.2));
> INSERT INTO numrange_test2 VALUES(numrange(1.1, 2.2));
> INSERT INTO numrange_test2 VALUES(numrange(1.1, 2.2,'()'));
> INSERT INTO numrange_test2 VALUES('empty');
>
> select * from numrange_test2 where nr = 'empty'::numrange;
> select * from numrange_test2 where nr = numrange(1.1, 2.2);
> select * from numrange_test2 where nr = numrange(1.1, 2.3);
>
> (None of that is surprising, right? :-)
>
> So that seems like more confirmation that it was always intended to be
> a hash index.
Yes, it indicates that.
Jeff/Heikki, to me the issue pointed by Paul looks like an oversight
in commit 4429f6a9e3. Can you think of any other reason? If not, I
can commit this patch.
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
