On Tue, 25 Jan 2022 at 14:44, Peter Eisentraut < peter.eisentr...@enterprisedb.com> wrote:
> 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?
