Re: Proposal: Global Index
От | Jeremy Schneider |
---|---|
Тема | Re: Proposal: Global Index |
Дата | |
Msg-id | b1159ce3-4c42-5977-f061-9cd7cc1d8d2a@amazon.com обсуждение исходный текст |
Ответ на | Re: Proposal: Global Index (Jeremy Schneider <schnjere@amazon.com>) |
Ответы |
Re: Proposal: Global Index
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: