On Mon, Nov 25, 2019 at 03:44:39PM -0800, Jeremy Schneider wrote: > On 11/25/19 15:05, Jeremy Schneider wrote: > > ... the cost of doing the individual index lookups across 180 > > partitions (and 180 indexes) was very high, so they stored max and min > > txn id per partition and would generate a query with all the dates that > > a txn id could have been in so that only a small number of partition > > indexes would be accessed. > > > > .. If we are looking for higher concurrency, we can usually > > add a hack/workaround that filters on a partition key to provide “pretty > > good” pruning. The net result is that you get 2-3x the IO due to the > > lack of global index (same workaround as first story above). > > Is that basically like a global BRIN index with granularity at the > partition level?
Exactly! :-) -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +
