On Thu, Jun 15, 2023, at 11:44, jian he wrote:
> In hashset/test/sql/order.sql, can we add the following to test whether
> the optimizer will use our index.
>
> CREATE INDEX ON test_int4hashset_order (int4hashset_col
> int4hashset_btree_ops);
>
> -- to make sure that this work with just two rows
> SET enable_seqscan TO off;
>
> explain(costs off) SELECT * FROM test_int4hashset_order WHERE
> int4hashset_col = '{1,2}'::int4hashset;
> reset enable_seqscan;
Not sure I can see the value of that test,
since we've already tested the comparison functions,
which are used by the int4hashset_btree_ops operator class.
I think a test that verifies the btree index is actually used,
would more be a test of the query planner than hashset.
I might be missing something here, please tell me if so.
> Since most contrib modules, one module, only one test file, maybe we
> need to consolidate all the test sql files to one sql file
> (int4hashset.sql)?
I've also made the same observation; I wonder if it's by design
or by coincidence? I think multiple test files improves modularity,
isolation and overall organisation of the testing.
As long as we are developing in the pre-release phase,
I think it's beneficial and affordable with rigorous testing.
However, if hashset would ever be considered
for core inclusion, then we should consolidate all tests into
one file and retain only essential tests, thereby minimizing
impact on PostgreSQL's overall test suite runtime
where every millisecond matters.
> Attached is a patch slightly modified README.md. feel free to change,
> since i am not native english speaker...
>
> Attachments:
> * 0001-add-instruction-using-PG_CONFIG-to-install-extension.patch
Thanks, improvements incorporated with some minor changes.
/Joel
