| From: | Jeremy Schneider <schnjere(at)amazon(dot)com> |
|---|---|
| To: | Bruce Momjian <bruce(at)momjian(dot)us>, Jose Luis Tallon <jltallon(at)adv-solutions(dot)net> |
| Cc: | Andres Freund <andres(at)anarazel(dot)de>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "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>, heikki(dot)linnakangas <heikki(dot)linnakangas(at)iki(dot)fi> |
| Subject: | Re: Proposal: Global Index |
| Date: | 2019-12-19 19:28:55 |
| Message-ID: | 92bde8c1-bf8a-a5c2-8dfa-7d368b739213@amazon.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 12/19/19 08:12, Bruce Momjian wrote:
> I don't see lossy BRIN indexes helping with the uniqueness use-case, and
> I am not sure they would help with the rare case either. They would
> help for range-based partitions, but I thought our existing facilities
> worked in that case.
Correlated data. The existing facilities work if the filtering column
is exactly the same as the partition column. But it's not at all
uncommon to have other columns with correlated data, perhaps the most
obvious of which is timeseries tables with many date columns of various
definitions (row first update, row latest update, invoice date, payment
date, process date, ship date, etc).
What if you could use *two* indexes in a single execution plan? Use the
global BRIN to narrow down to 2 or 3 out of a hundred or more
partitions, then use local indexes to find specific rows in the
partitions of interest? That might work, without being too overly
complicated.
-J
--
Jeremy Schneider
Database Engineer
Amazon Web Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2019-12-19 19:57:01 | Re: global / super barriers (for checksums) |
| Previous Message | Robert Haas | 2019-12-19 19:27:01 | Re: Optimizing TransactionIdIsCurrentTransactionId() |