Re: slow information schema with thausand users, seq.scan pg_authid

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: slow information schema with thausand users, seq.scan pg_authid
Дата
Msg-id 28422.1139253029@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: slow information schema with thausand users, seq.scan pg_authid  (Andrew - Supernews <andrew+nonews@supernews.com>)
Ответы Re: slow information schema with thausand users, seq.scan pg_authid  ("Pavel Stehule" <pavel.stehule@hotmail.com>)
Список pgsql-hackers
Andrew - Supernews <andrew+nonews@supernews.com> writes:
> On 2006-02-06, Peter Eisentraut <peter_e@gmx.net> wrote:
>> It already has indexes.

> True, but they're not being used where you'd expect. This seems to be
> something to do with the fact that it's not pg_authid which is being
> accessed, but rather the view pg_roles.

I looked into this and it seems the problem is that the view doesn't
get flattened into the main query because of the has_nullable_targetlist
limitation in prepjointree.c.  That's triggered because pg_roles has'********'::text AS rolpassword
which isn't nullable, meaning it would produce wrong behavior if
referenced above the outer join.

Ultimately, the reason this is a problem is that the planner deals only
in simple Vars while processing joins; it doesn't want to think about
expressions.  I'm starting to think that it may be time to fix this,
because I've run into several related restrictions lately, but it seems
like a nontrivial project.

In the meantime, reducing the LEFT JOIN to pg_roles to a JOIN as per
Peter's suggestion seems like the best short-term workaround.
        regards, tom lane


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

Предыдущее
От: Josh Berkus
Дата:
Сообщение: Re: Copy From & Insert UNLESS
Следующее
От: Stephan Szabo
Дата:
Сообщение: Re: Copy From & Insert UNLESS