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
