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

On Sat, Jul 16, 2016 at 1:32 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> It is pretty awkward how the hash index searches are in
>> hash_index.sql, which must coordinate with create_index.sql, but I
>> didn't want to go against the grain and just put it all in one place.
>> Maybe I should have.
>
> Well, that structure is intended to work with indexes that are built and
> then left in place throughout the tests.  For a short-lived index, the
> best thing is to create it, test it, drop it, and really you can do that
> about anywhere.  But again, doing that on tenk1 is problematic because
> of its popularity in all sorts of query-planning tests; if you're going
> to add a short-lived index you need to do that in a test that's not meant
> to run concurrently with a lot of other stuff.

I did think that the "fillfactor = 10" bloat would have prevented
problems with plan stability, but I accept that that might not be good
enough.

> Another approach we could have taken is to construct a table just for
> this purpose.

I actually started with that.

Anyway, test coverage of tuplesort.c seems in much better shape now.
The strategy of not always moving the tests towards the code, but
rather moving the code towards the tests (improving code testability)
seems to have been more effective than I'd anticipated.

My unpublished parallel CREATE INDEX patch forces a single worker,
single leader (deterministic division of labor) "serial parallel" sort
for every CREATE INDEX statement when force_parallel_mode is set to
'regress'. That's a nice thing to have for testing, because the
determinism allows one to line things up just right, and reliably
tickle certain classes of bug (this made a certain amount of TDD
possible). This configuration is only useful for testing, and is not
htat different to forcing an external sort, the notable difference
being that the worker process is still reliably subject to the general
limitations of parallel sort worker processes.

--
Peter Geoghegan