| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com> |
| Cc: | pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: surprisingly expensive join planning query |
| Date: | 2019-12-02 22:54:11 |
| Message-ID: | 18669.1575327251@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com> writes:
>> (Speaking of which, I don't quite see why this would have been a problem
>> once you got past geqo_threshold; the context resets that GEQO does
>> should've kept things under control.)
> Not sure I follow. geqo_threshold is 12 by default, and the OOM issues
> are hapenning way before that.
Ah, right. But would the peak memory usage keep growing with more than 12
rels?
> It might be that one reason why this example is so bad is that the CTEs
> have *exactly* the different join orders are bound to be costed exactly
> the same I think.
Hmm. I didn't really look into exactly why this example is so awful.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alexander Korotkov | 2019-12-03 00:00:03 | Re: [PATCH] kNN for btree |
| Previous Message | Thomas Munro | 2019-12-02 22:52:31 | Re: Since '2001-09-09 01:46:40'::timestamp microseconds are lost when extracting epoch |