On 31.12.21 15:10, Simon Riggs wrote: >> The factor 10 is a reasonably safe assumption and helps avoid worst >> case behavior in bigger graph queries. However, the factor 10 is way >> too large for many types of graph query, such as where the path >> through the data is tight, and/or the query is written to prune bushy >> graphs, e.g. shortest path queries. The factor 10 should not be >> hardcoded in the planner, but should be settable, just as >> cursor_tuple_fraction is. > If you think this should be derived without parameters, then we would > want a function that starts at 1 for 1 input row and gets much larger > for larger input. The thinking here is that Graph OLTP is often a > shortest path between two nodes, whereas Graph Analytics and so the > worktable will get much bigger.
On the one hand, this smells like a planner hint. But on the other hand, it doesn't look like we will come up with proper graph-aware selectivity estimation system any time soon, so just having all graph OLTP queries suck until then because the planner hint is hardcoded doesn't seem like a better solution. So I think this setting can be ok. I think the way you have characterized it makes sense, too: for graph OLAP, you want a larger value, for graph OLTP, you want a smaller value.
Do you think there is a case to replace the 10x multiplier with "recursive_worktable_estimate" for total_rows calculation in the cost_recursive_union function too?