On 2/4/25 21:34, Joe Conway wrote:
> 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.
>
We already have join_search_hook_type. I haven't used that in the PoC,
because I wanted to use joinrels.c functions defined as static, etc.
The main challenge would be handling queries that have multiple of such
patterns. The current hook is expected to process the whole list, while
what we'd need is more like splitting the list into chunks (one chunk
per query pattern), and then calling the hooks to handle the chunks in
some order.
But I don't think the patch should be required to invent this. We don't
even have an example of a second pattern.
regards
--
Tomas Vondra
