On 20/3/26 15:02, Alexander Korotkov wrote:
> OK. I've pushed this. Let's go back to
> restrict_infos_logically_equal(). I'm still not convinced that we
> need to check if required_relids is singleton. Why we can ignore
> outer_relids for singleton, but can't do if, for instance, two
> relations involved?
Let's continue. In the attachment, the Tender's proposal that I changed
a little and added some tests.
As you can see in the tests, the SINGLETON limitation keeps duplicates
of clauses like 'a.x + b.y = c'.
This example shows the main flaw of this approach. Introducing the
restrict_infos_logically_equal(), we do a little more job than just the
equal() routine could because of the context where we call this function
and on which clauses.
But skipping all other RestrictInfo fields except required_relids seems
excessive. - see the example with security_level difference - ignoring
its value, we potentially might remove the clause with enforced security
level in favour of an unsecured one.
That's more, further some new optimisations might introduce more fields
into RestrictInfo that should be checked to correctly decide on the
equality, and we may forget to arrange this specific place.
So, formally it works, and making the following replacement, we close
the singleton issue:
- if (bms_membership(a->required_relids) == BMS_SINGLETON &&
- a->security_level == b->security_level)
+ if (bms_equal(a->required_relids, b->required_relids) &&
+ a->security_level == b->security_level &&
+ a->is_pushed_down == b->is_pushed_down)
but I'm unsure, in general, that this approach is conservative enough.
Maybe we shouldn’t change this logic and invent one more optimisation
‘deduplication’ stage later, before the selectivity estimation stage.
--
regards, Andrei Lepikhov,
pgEdge
