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?
-J
--
Jeremy Schneider
Database Engineer
Amazon Web Services
