Re: Getting fancy errors when accessing information_schema on 10.5

Поиск
Список
Период
Сортировка
От Axel Rau
Тема Re: Getting fancy errors when accessing information_schema on 10.5
Дата
Msg-id EC747F72-288E-4F97-A56E-BD54D9507B4D@Chaos1.DE
обсуждение исходный текст
Ответ на Re: Getting fancy errors when accessing information_schema on 10.5  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Getting fancy errors when accessing information_schema on 10.5  (Laurenz Albe <laurenz.albe@cybertec.at>)
Re: Getting fancy errors when accessing information_schema on 10.5  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-admin


Am 30.10.2018 um 14:45 schrieb Tom Lane <tgl@sss.pgh.pa.us>:

Laurenz Albe <laurenz.albe@cybertec.at> writes:
Tom Lane wrote:
It doesn't happen for me either.  Looking at the planner code, it seems
like the relkind check should happen first because it'd be cheaper than
the OR condition.

It is still unclear why the execution plan looks like that, but maybe
it would be more robust to change "has_sequence_privilege" so that it
just returns FALSE if the argument is not a sequence.

I was wondering about that, but somewhere along there we'd be losing
all semblance of error checking on the OID argument, so it's not all
that attractive a solution.  I'd prefer to understand why this isn't
behaving the same as it does for other people before we resort to that.

Axel, would you try two more things on that DB?

explain select ((pg_has_role(relowner, 'USAGE'::text) OR has_sequence_privilege(oid, 'SELECT, UPDATE, USAGE'::text))) from pg_class;

explain select (relkind = ’S'::"char") from pg_class;

nextcloud=> explain select ((pg_has_role(relowner, 'USAGE'::text) OR has_sequence_privilege(oid, 'SELECT, UPDATE, USAGE'::text))) from pg_class;
                        QUERY PLAN                         
-----------------------------------------------------------
 Seq Scan on pg_class  (cost=0.00..28.56 rows=656 width=1)
(1 row)

nextcloud=> explain select (relkind = 'S'::"char") from pg_class;
                        QUERY PLAN                         
-----------------------------------------------------------
 Seq Scan on pg_class  (cost=0.00..28.56 rows=656 width=1)
(1 row)


That's just to positively confirm that the planner thinks the former
expression is more expensive than the latter.

Assuming that it does, the only other answer I can think of is that
there's something wrong with the insertion sort code in
order_qual_clauses.  Pretty hard to see what, though.

Axel
---
PGP-Key:29E99DD6  ☀  computing @ chaos claudius

В списке pgsql-admin по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Getting fancy errors when accessing information_schema on 10.5
Следующее
От: Laurenz Albe
Дата:
Сообщение: Re: Getting fancy errors when accessing information_schema on 10.5