Re: Analyze all plans

On Jan 23, 2019, at 6:46 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> Oleksandr Shulgin <oleksandr(dot)shulgin(at)zalando(dot)de> writes:
>> On Wed, Jan 23, 2019 at 9:44 AM Donald Dong <xdong(at)csumb(dot)edu> wrote:
>>> 1. Enumerate all the plans
>
>> So enumerating all possible plans stops being practical for even slightly
>> complicated queries.
>
> Yes. You can *not* disable the planner's aggressive pruning of losing
> paths and subpaths without ending up with something that's completely
> impractical for anything beyond toy queries. That's just from the
> standpoint of planner runtime. Adding on the cost of actually creating
> a finished plan and then running it for long enough to get a reliable
> runtime for each case would ... well, let's just say you'd be safely dead
> before you got any interesting answers.

Thank you for the feedback. I didn't think about this carefully. I
thought the planner would use GEQO when the number of joins is
large, but indeed it's still n! for normal path selection.

Now I keep top-k cheapest sub plans, where k is configured
by users. If the k is set up properly, setting a timeout may not
be necessary. However, if I do want to set a timeout, I would run
into the issues I had in step 2.

I'm looking forward to hearing more thoughts :)

Thanks again!