Re: Getting an index scan to be a parallel index scan - Mailing list pgsql-performance

Okay after reading http://rhaas.blogspot.com/2018/06/using-forceparallelmode-correctly.html I do see that I was using force_parallel_mode incorectly and wouldn't have gotten what I wanted even if the original query was possible to parallelize.

> Maybe, but unfairness multiplies if it's part of a larger plan

Ah, I didn't think of that, and it's a good point.

> Ok I hacked my copy of PostgreSQL to let me set parallel_setup_costs
> to negative numbers ...

Thanks for taking the time to do that and look into that.  I don't actually think it's worth the confusion to allow this in general, but I was thinking that setting "force_parallel_mode = on" would essentially be doing something equivalent to this (though I now see that is wrong).

> But it's probing every index for every one of the values in the big
> list, not just the ones that have a non-zero chance of finding a
> match, which is a waste of cycles.

In my case, this would actually be quite helpful because the real bottleneck when I run this in production is time spent waiting for IO.  I was hoping to spread that IO wait time over multiple threads, and wouldn't really care about the few extra wasted CPU cycles.  But I can't actually do this as I can't set parallel_setup_costs to be negative, so I wouldn't be able to get PG to choose the parallel plan even if I did partition the table.

> If I had more timerons myself ...

If only we all had more timerons ... :)

Thanks,
Alex Kaiser