Axel Rau <Axel.Rau@chaos1.de> writes:
>> Am 30.10.2018 um 16:04 schrieb Tom Lane <tgl@sss.pgh.pa.us>:
>> That is ... odd. Is it possible that you have cpu_operator_cost set
>> to zero, or some very tiny number?
> Yes:
> cpu_index_tuple_cost = 0.01
> cpu_operator_cost = 0
Ah, well that explains why the clauses are seen as being the same cost
--- the function procost values are scaled by cpu_operator_cost, and
twice zero is still zero.
It probably is not a bright idea to have things set that way.
I somewhat agree with Laurenz's idea of bumping up the procost
settings for the privilege-check functions, as that would help
prevent this sort of issue in future --- but it won't do anything
to help if cpu_operator_cost is zero.
Another thought here is that the reason the relkind check ended up
at the end in the first place is that it was torn apart to make an
EquivalenceClass, and then reassembled when we found we couldn't
do anything very interesting with the EC, and the reassembled clause
just gets tacked onto the end of the relevant clause list since we
no longer have any idea where it was in the list originally. So
that's how it is that order_qual_clauses found the entries in the
"wrong" order to start with. So one kluge worth thinking about is
to give some preference in the order_qual_clauses sort to clauses
that came from an EC. This isn't as totally random as it might
seem: EC clauses are less likely to have unpleasant side effects,
since you wouldn't normally expect an equality operator to fail.
But that only fixes it for cases like "relkind = something",
and a lot of the checks in the information_schema are more like
"relkind IN (x, y, z)". Those aren't handled as ECs; worse,
they'll have cost higher than one cpu_operator_cost. I'm a bit
surprised we've not seen other problems of this kind.
We may be forced to the other idea of reducing the relkind checks
to non-errors. At least now we understand why.
I wonder though: if you apply has_sequence_privilege() to a
non-sequence, or similar cases for other has_xxx functions,
should that result in FALSE, or NULL? It's not immediately
clear which answer is better.
regards, tom lane