public inbox for [email protected]
help / color / mirror / Atom feedFrom: Tom Lane <[email protected]>
To: David Rowley <[email protected]>
Cc: Chao Li <[email protected]>
Cc: PostgreSQL Developers <[email protected]>
Subject: Re: Add bms_offset_members() function for bitshifting Bitmapsets
Date: Tue, 14 Apr 2026 22:30:47 -0400
Message-ID: <[email protected]> (raw)
In-Reply-To: <CAApHDvq4_WDfTaWX6nHU8TV+no+aD1zjLphza685Ek7=xgGzew@mail.gmail.com>
References: <CAApHDvq=eEdw2Qp+aSzSOtTSe+h0fnVQ55CcTNqBkLDYiRZmxw@mail.gmail.com>
<[email protected]>
<CAApHDvoALVPgVSCuGdAfNUbxx_NacnAd0nuj8Hi=_-61AEqzaQ@mail.gmail.com>
<[email protected]>
<CAApHDvq4_WDfTaWX6nHU8TV+no+aD1zjLphza685Ek7=xgGzew@mail.gmail.com>
David Rowley <[email protected]> writes:
> On Wed, 15 Apr 2026 at 12:29, Tom Lane <[email protected]> wrote:
>> I question the decision to make this change the set in-place.
>> Wouldn't it be cheaper and less surprise-prone to always make
>> a copy?
> I'd not considered surprise-prone as an aspect. I understand we have
> bms_join and bms_union, which do the same thing if you only care about
> the value of the result and not what happens to the inputs.
Sure, but bms_join is an optional optimization of the far safer
bms_union operation. It bothers me to create the optimized case
but not the base case.
regards, tom lane
view thread (15+ messages) latest in thread
reply
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: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected]
Subject: Re: Add bms_offset_members() function for bitshifting Bitmapsets
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox