Jerry Champlin wrote: > If it were implemented in such a way that when the top level pruning > happens, a set of 3 sub partitions is selected from say 18 total and then at > the next level is selects the 3 matching sub partitions from each matched > group of 30 then you are only looking at 18+3*30 = 108 instead of 548 checks > to evaluate <example assumes monthly first level partitioning and daily sub > partitioning>. If this is not supported, then we will need to solve the > problem a different way - probably weekly partitions and refactor the code > to decrease updates by at least an order of magnitude. While we are in the > process of doing this, is there a way to make updates faster? Postgresql is > spending a lot of CPU cycles for each HOT update. We have > synchronous_commit turned off, commit siblings set to 5, commit_delay set to > 50,000. Perhaps you do not realize this, but this is an exciting report to read. Not many years ago, this kind of system would have been unthinkable. We've now tuned the system so that people is starting to consider it, and for a lot of people it is working. -- Alvaro Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support
