Re: should we have a fast-path planning for OLTP starjoins?

On 2/4/25 09:00, Tomas Vondra wrote:
> There's a lot of stuff that could / should be improved on the current
> patch. For (1) we might add support for more complex cases with
> snowflake schemas [3] or with multiple fact tables. At the same time (1)
> needs to be very cheap, so that it does not regress every non-starjoin
> query.
> 
> For (2) it might pick a particular order we join the dimensions (by
> size, selectivity, ...), and it might consider whether to join them
> before/after the other relations.
> 
> FWIW I suspect there's a fair amount of research papers looking at
> starjoins and what is the optimal plan for such queries, but I didn't
> have time to look at that yet. Pointers welcome!
> 
> But the bigger question is whether it makes sense to have such fast-path
> modes for certain query shapes. The patch "hard-codes" the planning for
> starjoin queries, but we clearly can't do that for every possible join
> shape (because then why have dynamic join search at all?).

+    /*
+     * Try simplified planning for starjoin. If it succeeds, we should
+     * continue at level startlev.
+     */
+    startlev = starjoin_join_search(root, initial_rels, 2);

(I should probably don a flame retardant suit, but...)

This sounds like an interesting idea, but it makes me wonder if we 
should have a more generic mechanism here so that if "some pattern is 
matched" then "use some simplified planning method" -- of which the 
starjoin is the first and builtin example, but allowing for others to be 
plugged in via extensions.

-- 
Joe Conway
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com