| From: | "Tsunakawa, Takayuki" <tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com> |
|---|---|
| To: | 'Amit Langote' <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp> |
| Cc: | 'David Rowley' <david(dot)rowley(at)2ndquadrant(dot)com>, "Imai, Yoshikazu" <imai(dot)yoshikazu(at)jp(dot)fujitsu(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | RE: speeding up planning with partitions |
| Date: | 2019-02-08 03:41:45 |
| Message-ID: | 0A3221C70F24FB45833433255569204D1FB961EA@G01JPEXMBYT05 |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi Amit,
From: Amit Langote [mailto:Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp]
> Maybe I chose the the subject line of this thread poorly when I began
> working on it. It should perhaps have been something like "speeding up
> planning of point-lookup queries with many partitions" or something like
> that. There are important use cases beyond point lookup even with
> partitioned tables (or maybe more so with partitioned tables), but perhaps
> unsurprisingly, the bottlenecks in those cases are not *just* in the
> planner.
No, it's simply my fault. I wasn't aware of the CF Bot and the CF entry page that act on the latest submitted patch. I'm relieved to see you have submitted the revised patch.
Regards
Takayuki Tsunakawa
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Geoghegan | 2019-02-08 03:43:15 | Re: Fixing findDependentObjects()'s dependency on scan order (regressions in DROP diagnostic messages) |
| Previous Message | Tom Lane | 2019-02-08 03:35:34 | Re: Fixing findDependentObjects()'s dependency on scan order (regressions in DROP diagnostic messages) |