public inbox for [email protected]
help / color / mirror / Atom feedFrom: Alvaro Herrera <[email protected]>
To: Amit Langote <[email protected]>
Cc: Ian Lawrence Barwick <[email protected]>
Cc: Tom Lane <[email protected]>
Cc: David Rowley <[email protected]>
Cc: Greg Stark <[email protected]>
Cc: Julien Rouhaud <[email protected]>
Cc: PostgreSQL Hackers <[email protected]>
Subject: Re: ExecRTCheckPerms() and many prunable partitions
Date: Tue, 29 Nov 2022 10:27:08 +0100
Message-ID: <[email protected]> (raw)
In-Reply-To: <CA+HiwqHQeooqvXy+FSXYOq0wajGtC5-TBj0=ZW1=qVq5Pm2ycw@mail.gmail.com>
Thanks for the new version, in particular thank you for fixing the
annoyance with the CombineRangeTables API.
0002 was already pushed upstream, so we can forget about it. I also
pushed the addition of missing_ok to build_attrmap_by_name{,_if_req}.
So this series needed a refresh, which is attached here, and tests are
running: https://cirrus-ci.com/build/4880219807416320
As for 0001+0003, here it is once again with a few fixups. There are
two nontrivial changes here:
1. in get_rel_all_updated_cols (née GetRelAllUpdatedCols, which I
changed because it didn't match the naming style in inherits.c) you were
doing determining the relid to use in a roundabout way, then asserting
it is a value you already know:
- use_relid = rel->top_parent_relids == NULL ? rel->relid :
- bms_singleton_member(rel->top_parent_relids);
- Assert(use_relid == root->parse->resultRelation);
Why not just use root->parse->resultRelation in the first place?
My 0002 does that.
2. my 0005 moves a block in add_rte_to_flat_rtable one level out:
there's no need to put it inside the rtekind == RTE_RELATION block, and
the comment in that block failed to mention that we copied the
RTEPermissionInfo; we can just let it work on the 'perminfoindex > 0'
condition. Also, the comment is a bit misleading, and I changed it
some, but maybe not sufficiently: after add_rte_to_flat_rtable, the same
RTEPermissionInfo node will serve two RTEs: one in the Query struct,
whose perminfoindex corresponds to Query->rtepermlist; and the other in
PlannerGlobal->finalrtable, whose index corresponds to
PlannerGlobal->finalrtepermlist. I was initially thinking that the old
RTE would result in a "corrupted" state, but that doesn't appear to be
the case. (Also: I made it grab the RTEPermissionInfo using
rte->perminfoindex, not newrte->perminfoindex, because that seems
slightly bogus, even if they are identical because of the memcpy.)
The other changes are cosmetic.
I do not include here your 0004 and 0005. (I think we can deal with
those separately later.)
--
Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
view thread (78+ 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], [email protected], [email protected], [email protected], [email protected]
Subject: Re: ExecRTCheckPerms() and many prunable partitions
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