Re: Query on partitioned table needs memory n_partitions * work_mem
Dimitrios Apostolou <jimis@gmx.net>
From: Dimitrios Apostolou <jimis@gmx.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: David Rowley <dgrowleyml@gmail.com>, pgsql-general@lists.postgresql.org
Date: 2024-07-11T15:19:42Z
Lists: pgsql-general
On Thu, 11 Jul 2024, Tom Lane wrote: > Dimitrios Apostolou <jimis@gmx.net> writes: >> The TABLE test_runs_raw has 1000 partitions on RANGE(workitem_n). > > So don't do that. Adding partitions is not cost-free. > I understand that, they also add an administrative cost that I'd rather avoid. But I ended up adding all these partitions because of performance issues on a multi-billion rows table. There is probably some message from me on this list a couple of years ago. At the moment I have a work-around. I'm thankful that everyone is willing to provide workarounds to all potential issues/bugs I have presented, but unfortunately workarounds are not fixes, one will hit the same wall again at some point. My current concern is **reporting my findings responsibly**. I want to provide as much data needed to pinpoint the issue, so that the developers know exactly what's going on. Having right data is half the fix. A way to track the issue would be nice. I might revisit it and even try to submit a patch. I wonder how the postgres development community is tracking all these issues, I've even started forgetting the ones I have found, and I'm sure I have previously reported (on this list) a couple of should-be-easy issues that would be ideal for beginners. Regards, Dimitris
Commits
-
Doc: mention executor memory usage for enable_partitionwise* GUCs
- 447e25c04915 12.20 landed
- 5eea78af2d3c 13.16 landed
- 51895d08b41a 14.13 landed
- 27146e79bf03 15.8 landed
- a459e583e06b 16.4 landed
- 3256722d7b7f 17.0 landed
- 057ee9183c21 18.0 landed