Re: Hash-based MCV matching for large IN-lists

In the thread discussing ALL semantics and NULL [0], the question was 
raised about adding a new regression test that checks selectivity 
estimation. If the change gets committed, it would make sense to add 
tests for this case as well.

Regarding the idea of optimizing the loop when all per-element 
selectivities are the same: I ran some quick tests to see how much the 
change in the v7-0002 patch affects planning time. Even without that 
patch, iterating over an array with 50k elements takes about 30 ms.

```
CREATE TABLE t (val bytea PRIMARY KEY);
INSERT INTO t SELECT int4send(i) FROM generate_series(1,50000) AS i;
ANALYZE t;
SELECT n_distinct FROM pg_stats WHERE tablename = 't';
  n_distinct
------------
          -1
(1 row)

SELECT string_agg(format('int4send(%s)', i), ',') FROM 
generate_series(1,50000) AS i \gset
EXPLAIN (SUMMARY) SELECT * FROM t WHERE val = ANY 
(ARRAY[:string_agg]::bytea[]);
..........
  Planning Time: 32.816 ms
(3 rows)
```

Given that, I don't see much benefit in adding additional logic here 
just to avoid the loop. It would likely introduce extra code complexity 
without a manful gain. If there is interest in optimization this case 
further, I can revisit it and add the additional patch.

The patch v8 can still be reviewed as-is, and if the selectivity 
regression test gets committed [0], I will add corresponding tests for 
this change as well.

[0]: 
https://www.postgresql.org/message-id/390a46f3-dbc4-4dc1-b49d-5cc61dd36026%40tantorlabs.com

-- 
Best regards,
Ilia Evdokimov,
Tantor Labs LLC,
https://tantorlabs.com/