Re: BUG #18588: Cannot force/let database use parallel execution in simple case.

I wrote:
> Hmm, you can see both behaviors on the small version of t1, just by
> varying the comparison constant in the WHERE clause.  For me, it'll
> use only one worker with "where a<1", and not parallelize at all
> with "where a<0".  It looks like it's deciding that it's not worth
> starting workers when too few rows are expected to be returned.  That
> would be unsurprising with a normal setting of parallel_setup_cost,
> but it does seem odd with parallel_setup_cost=0.

Ah, I traced through it, and here's what's happening: at small enough
estimated rowcounts, the parallel and non-parallel plans have fuzzily
the same cost (parallel is a shade cheaper, but only a shade).
Their other properties such as pathkeys are the same too.  So we get
to the tie-breaking logic in add_path, and what breaks the tie is
the difference in parallel safety: the non-parallel plan is marked
parallel_safe and the parallel one (which by this point is a Gather)
is not.

That tie-break rule is not wrong, because preserving parallel safety
can be a good thing when we come to consider use of the path at higher
plan levels.  So I think there's nothing to see here.

            regards, tom lane