| From: | Jeremy Schneider <schnjere(at)amazon(dot)com> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Peter Geoghegan <pg(at)bowt(dot)ie>, Robert Haas <robertmhaas(at)gmail(dot)com>, "Ibrar Ahmed" <ibrar(dot)ahmad(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Amit Langote <amitlangote09(at)gmail(dot)com>, Hamid Akhtar <hamid(dot)akhtar(at)gmail(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, heikki(dot)linnakangas <heikki(dot)linnakangas(at)iki(dot)fi> |
| Subject: | Re: Proposal: Global Index |
| Date: | 2019-11-25 23:44:39 |
| Message-ID: | b1159ce3-4c42-5977-f061-9cd7cc1d8d2a@amazon.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Phil Florent | 2019-11-26 00:16:49 | RE: GROUPING SETS and SQL standard |
| Previous Message | Jeremy Schneider | 2019-11-25 23:05:03 | Re: Proposal: Global Index |