On Jan 23, 2019, at 6:46 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Oleksandr Shulgin <oleksandr.shulgin@zalando.de> writes:
>> On Wed, Jan 23, 2019 at 9:44 AM Donald Dong <xdong@csumb.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!
