From: Paul Jungwirth <pj@illuminatedcomputing.com>
To: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Cc: Jeff Davis <pgsql@j-davis.com>
Cc: Pavel Stehule <pavel.stehule@gmail.com>
Cc: David Fetter <david@fetter.org>
Subject: Re: range_agg
Date: Mon, 23 Mar 2020 21:23:31 -0700
Message-ID: <1d40004c-335a-a268-454e-6864e188c852@illuminatedcomputing.com> (raw)
In-Reply-To: <20200323233227.GA5607@alvherre.pgsql>
References: <20200323233227.GA5607@alvherre.pgsql>
Thanks Alvaro!
On Mon, Mar 23, 2020 at 4:33 PM Alvaro Herrera
<alvherre@2ndquadrant.com> wrote:
>
> Thinking about the on-disk representation, can we do better than putting
> the contained ranges in long-varlena format, including padding; also we
> include the type OID with each element. Sounds wasteful. A more
> compact representation might be to allow short varlenas and doing away
> with the alignment padding, put the the type OID just once. This is
> important because we cannot change it later.
Can you give me some guidance on this? I don't know how to make the
on-disk format different from the in-memory format. (And for the
in-memory format, I think it's important to have actual RangeTypes
inside the multirange.) Is there something in the documentation, or a
README in the repo, or even another type I can follow?
> I'm also wondering if multirange_in() is the right strategy. Would
it> be sensible to give each range to range_parse or range_parse_bounde, so
> that it determines where each range starts and ends? Then that function
> doesn't have to worry about each quote and escape, duplicating range
> parsing code. (This will probably require changing signature of the
> rangetypes.c function, and exporting it; for example have
> range_parse_bound allow bound_str to be NULL and in that case don't mess
> with the StringInfo and just return the end position of the parsed
> bound.)
Yeah, I really wanted to do it that way originally too. As you say it
would require passing back more information from the range-parsing code.
I can take a stab at making the necessary changes. I'm a bit more
confident now than I was then in changing the range code we have already.
Regards,
--
Paul ~{:-)
pj@illuminatedcomputing.com
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: pj@illuminatedcomputing.com, alvherre@2ndquadrant.com, tgl@sss.pgh.pa.us, pgsql@j-davis.com, pavel.stehule@gmail.com, david@fetter.org
Subject: Re: range_agg
In-Reply-To: <1d40004c-335a-a268-454e-6864e188c852@illuminatedcomputing.com>
* 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