From: Alvaro Herrera <alvherre@2ndquadrant.com>
To: Tomas Vondra <tomas.vondra@2ndquadrant.com>
Cc: John Naylor <john.naylor@2ndquadrant.com>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: WIP: BRIN multi-range indexes
Date: Wed, 9 Sep 2020 16:53:30 -0300
Message-ID: <20200909195330.GA16854@alvherre.pgsql> (raw)
In-Reply-To: <20200909193530.x57p5nzawryndxzj@development>
On 2020-Sep-09, Tomas Vondra wrote:
> There are some minor optimizations possible - for example I noticed we
> call minmax_multi_get_strategy_procinfo often because it happens in a
> loop, and we could easily do it just once. But that saves only about 10%
> or so, it's not a ground-breaking optimization.
Well, I guess this kind of thing should be fixed regardless while we
still know it's there, just to avoid an obvious inefficiency.
> The main reason for the slowness is that we pass the values one by one
> to brin_minmax_multi_add_value - and on each call we need to deserialize
> (and then sometimes also serialize) the summary, which may be quite
> expensive. The regular minmax does not have this issue, it just swaps
> the Datum value and that's it.
Ah, right, that's more interesting. The original dumb BRIN code
separates BrinMemTuple from BrinTuple so that things can be operated
efficiently in memory. Maybe something similar can be done in this
case, which also sounds like your second suggestion:
> Another option would be to teach add_value to keep the deserialized
> summary somewhere, and then force serialization at the end of the BRIN
> page range. The end result would be roughly the same, I think.
Also, I think you could get a few initial patches pushed soon, since
they look like general improvements rather than specific to multi-range.
On a differen train of thought, I wonder if we shouldn't drop the idea
of there being two minmax opclasses; just have one (still called
"minmax") and have the multi-range version be the v2 of it. We would
still need to keep code to operate on the old one, but if you ever
REINDEX then your index is upgraded to the new one. I see no reason to
keep the dumb minmax version around, assuming the performance is roughly
similar.
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: alvherre@2ndquadrant.com, tomas.vondra@2ndquadrant.com, john.naylor@2ndquadrant.com
Subject: Re: WIP: BRIN multi-range indexes
In-Reply-To: <20200909195330.GA16854@alvherre.pgsql>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox