Re: range_agg extremely slow compared to naive implementation in obscure circumstances - Mailing list pgsql-bugs

From Alvaro Herrera
Subject Re: range_agg extremely slow compared to naive implementation in obscure circumstances
Date
Msg-id 20230201115741.qfcjbm4jyji4etvn@alvherre.pgsql
Whole thread Raw
In response to Re: range_agg extremely slow compared to naive implementation in obscure circumstances  (David Rowley <dgrowleyml@gmail.com>)
Responses Re: range_agg extremely slow compared to naive implementation in obscure circumstances  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-bugs
On 2023-Jan-31, David Rowley wrote:

> It might be better if we had multirange_canonicalize() deserialize
> these once and used some representation that could more easily be
> qsorted. I'm not planning on doing any work on it though.

Yeah, maybe it would be possible to have an in-memory representation
that doesn't require any deparsing, and keep the compact representation
to be used only for in-data-page storage.  How to do this within the
constraints of the Datum abstraction is not clear to me.

-- 
Álvaro Herrera         PostgreSQL Developer  —  https://www.EnterpriseDB.com/
"El sabio habla porque tiene algo que decir;
el tonto, porque tiene que decir algo" (Platon).



pgsql-bugs by date:

Previous
From: hubert depesz lubaczewski
Date:
Subject: Re: BUG #17766: Issue in asc, limit and offset for pagination.
Next
From: Tom Lane
Date:
Subject: Re: BUG #17767: psql: tab-completion causes warnings when standard_conforming_strings = off