While investigating a performance issue, I found that it was extremely
difficult to get a parallel plan in some cases due to the fixed
parallel_tuple_cost. But this cost is not really fixed - it's going to
be larger for larger tuples. So this proposal adjusts the cost used
according to how large we expect the results to be. The result is that
in the common case where, say, you're getting a group id and some
aggregates, a parallel plan is more likely to be chosen. By contrast,
queries that generate very wide results will be less likely to choose
parallel plans. The formula chosen does have a fixed cost piece built
into it, which accounts for the shm_mq_sendv() and shm_mq_receive()
synchronization that occurs regardless of width.
The patch itself is pretty simple.
Also attached is a benchmark report that I had claude create. Its main
result shows a speedup of about 2.7x.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
