| From: | Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp> |
|---|---|
| To: | David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>, "Kato, Sho" <kato-sho(at)jp(dot)fujitsu(dot)com> |
| Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Planning time of Generic plan for a table partitioned into a lot |
| Date: | 2018-11-30 02:04:19 |
| Message-ID: | 81e3a1c2-80cb-3e3b-f4b2-441cd1d76df3@lab.ntt.co.jp |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 2018/11/29 19:54, David Rowley wrote:
> The problem is only made worse in PG11 from PG10
> because generating the custom plan has become faster than it
> previously was due to the new partition pruning code which might make
> it appear we can handle more partitions than we could previously,
Actually, PG 11's pruning improvements don't change plancache.c's equation
of custom plan cost, that is, even if pruning may have gotten faster it
doesn't change the value cached_plan_cost comes up with.
Although, you're certainly right that users are well advised to trust the
documentation to not go beyond hundreds of partitions, even if they may
not care about all the internal details that make partitioning slow.
Thanks,
Amit
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Yamaji, Ryo | 2018-11-30 02:06:12 | RE: [HACKERS] Cached plans and statement generalization |
| Previous Message | Michael Paquier | 2018-11-30 02:02:33 | Re: pgsql: Add TAP tests for pg_verify_checksums |