| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Oleksandr Shulgin <oleksandr(dot)shulgin(at)zalando(dot)de> |
| Cc: | Donald Dong <xdong(at)csumb(dot)edu>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Analyze all plans |
| Date: | 2019-01-23 14:46:39 |
| Message-ID: | 25986.1548254799@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Dmitry Dolgov | 2019-01-23 15:12:15 | Re: ArchiveEntry optional arguments refactoring |
| Previous Message | maayan mordehai | 2019-01-23 13:05:49 | Re: postgres on a non-journaling filesystem |