2 comments

  • abelanger1 hour ago
    I mentioned this towards the bottom of the post, but to reiterate: we&#x27;re extremely grateful to Laurenz for helping us out here, and his post on this is more than worth checking out: <a href="https:&#x2F;&#x2F;www.cybertec-postgresql.com&#x2F;en&#x2F;partitioned-table-statistics&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.cybertec-postgresql.com&#x2F;en&#x2F;partitioned-table-sta...</a><p>(plus an interesting discussion in the comments of that post on how the query planner chose a certain row estimate in the specific case that Laurenz shared!)<p>The other thing I&#x27;ll add is that we still haven&#x27;t figured out:<p>1. An optimal ANALYZE schedule here on parent partitions; we&#x27;re opting to over-analyze than under-analyze at the moment, because it seems like our query distribution might change quite often.<p>2. Whether double-partitioned tables (we have some tables partitioned by time series first, and an enum value second) need analyze on the intermediate tables, or whether the top-level parent and bottom-level child tables are enough. So far just the top-level and leaf tables seem good enough.
  • groundzeros20151 hour ago
    They didn’t say why they didn’t use the built-in partitioning system.
    • Tostino42 minutes ago
      They are using the built-in partitioning. They just ran into one of the &quot;you gotta know this&quot; pitfalls.