From: | Jose Luis Tallon <jltallon(at)adv-solutions(dot)net> |
---|---|
To: | Bruce Momjian <bruce(at)momjian(dot)us>, Jeremy Schneider <schnjere(at)amazon(dot)com> |
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 08:48:40 |
Message-ID: | 532eaed7-a399-792f-f792-760c8b411ca2@adv-solutions.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 19/12/19 4:03, Bruce Momjian wrote:
> 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! :-)
Actually, one "kind of" BRIN index *per partitioned table* mapping (key
range) -> (partition oid)... and so concurrency doesn't need to be very
affected.
(we don't need to do things just like other RDBMS do, ya know... ;)
IIRC, this precise approach was suggested around 2016 when initially
discussing the "declarative partitioning" which originated Postgres'
current partitioning scheme, in order to optimize partition pruning.
Just my .02€
/ J.L.
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2019-12-19 09:50:44 | Re: Read Uncommitted |
Previous Message | Michael Paquier | 2019-12-19 07:49:44 | Re: automating pg_config.h.win32 maintenance |