Re: Should we add GUCs to allow partition pruning to be disabled?
Amit Langote <langote_amit_f8@lab.ntt.co.jp>
From: Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>
To: David Rowley <david.rowley@2ndquadrant.com>
Cc: Justin Pryzby <pryzby@telsasoft.com>,
Alvaro Herrera <alvherre@2ndquadrant.com>,
Robert Haas <robertmhaas@gmail.com>,
Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>,
PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2019-03-11T02:13:22Z
Lists: pgsql-hackers
On 2019/03/11 11:00, David Rowley wrote: > On Mon, 11 Mar 2019 at 14:33, Amit Langote > <Langote_Amit_f8@lab.ntt.co.jp> wrote: >> PG 11 moved the needle a bit for SELECT queries: >> >> Excluding unnecessary partitions is slow for UPDATE and DELETE queries, > > With those words I expect the user might be surprised that it's still > slow after doing SET enable_partition_pruning = off; > > I'm not really talking about constraint exclusion or partition > pruning. The memory growth problem the user was experiencing was down > to the fact that we plan once per partition and each of the > PlannerInfos used for each planner run has a RangeTblEntry for all > partitions. This means if you add one more partition and you get N > partitions more RangeTblEntry items in memory. This is the quadratic > memory growth that I mentioned in the -general post. Yeah, I get it. As I said in my email, all we have ever mentioned in the documentation as the reason for queries on partitioned tables being slow is that partition exclusion is slow and nothing else. Can we put quadratic memory growth during planning as the reason for performance degradation into the documentation? Maybe we could, but every time I tried it, it didn't read like user-facing documentation to me. Do you have something in mind that we could add? Thanks, Amit
Commits
-
Tweak partitioning documentation wording
- 12b9affb32a6 11.0 landed
-
docs: Rework sections on partition pruning/exclusion
- bebc46931a12 11.0 landed
-
Add GUC enable_partition_pruning
- 055fb8d33da6 11.0 landed