Thomas, I tried to reproduce this case with changes you listed, but failed to do that - the number of results was the same on each run. Could you post an updated script in an attachment?
On Wed, Jan 9, 2019 at 2:52 PM Thomas Munro <thomas.munro@enterprisedb.com> wrote: > Now the number of results from the query in the script is not stable, > varying between 235 or 246 results for me. Not sure what's going on > yet.
When there are multiple matches found by the Index Scan, sometimes only the first one makes it through to the Nested Loop, in the leader. It's not because of single_match being inappropriately set as I speculated earlier (though that'd behave similarly I guess) but because the quals are somehow broken in between invocations so that ExecScan() filters the rest of the matches out, and then fixed again on the next rescan. This happens whenever the leader takes a break to read tuple from parallel workers in between executing the Nested Loop node, which it often does after reading the first of several tuples resulting from a single rescan.
What exactly is being corrupted and how, I don't yet know, and I need to leave this here for today, but that's what I've got so far.