Re: Should we make Bitmapsets a kind of Node? - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Re: Should we make Bitmapsets a kind of Node?
Date
Msg-id CAH2-WznG6dVZHMMAY1eBmAuvxuDNirn-wpBXdpmbM-W4B6dhGA@mail.gmail.com
Whole thread Raw
In response to Should we make Bitmapsets a kind of Node?  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Should we make Bitmapsets a kind of Node?  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Fri, Jan 29, 2021 at 12:12 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> I got annoyed (not for the first time) by the fact that the
> partitioned_rels field of AppendPath and MergeAppendPath is a list of
> Relids, i.e., Bitmapsets.  This is problematic because a Bitmapset is
> not a type of Node, and thus a List of them is really an invalid data
> structure.  The main practical consequence is that pprint() fails to
> print these path types accurately, which is an issue for debugging.

So we don't actually require T_List-type Lists to only contain entries
of type Node already? ISTM that T_List-type Lists cannot *mostly* be a
Node that consists of a collection of linked Nodes. It has to be
all-or-nothing. The "Node-ness" of a List should never be situational
or implicit -- allowing that seems like a recipe for disaster. This
kind of "code reuse" is not a virtue at all.

If tightening things up here turns out to be a problem someplace, then
I'm okay with that code using some other solution. That could mean
expanding the definition of a Node in some way that was not originally
considered (when it nevertheless makes sense), or it could mean using
some other data structure instead.

Might be good to Assert() that this rule is followed in certain key
list.c functions.

> We've had some related problems before, so I'm wondering if it's time
> to bite the bullet and turn Bitmapsets into legal Nodes.  We'd have
> to add a nodetag field to them, which is free on 64-bit machines due
> to alignment considerations, but would increase the size of most
> Bitmapsets on 32-bit machines.  OTOH, I do not think we're optimizing
> for 32-bit machines anymore.

+1 from me.

I'm prepared to say that 32-bit performance shouldn't be a concern
these days, except perhaps with really significant regressions. And
even then, only when there is no clear upside. If anybody really does
run Postgres 14 on a 32-bit platform, they should be much more
concerned about bugs that slip in because nobody owns hardware like
that anymore. It's probably much riskier to use 32-bit x86 today than
it is to use (say) POWER8, or some other contemporary minority
platform.

-- 
Peter Geoghegan



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Proposal: Save user's original authenticated identity for logging
Next
From: Tom Lane
Date:
Subject: Re: Should we make Bitmapsets a kind of Node?