Re: slow information schema with thausand users, seq.scan pg_authid - Mailing list pgsql-hackers

From Tom Lane
Subject Re: slow information schema with thausand users, seq.scan pg_authid
Date
Msg-id 28422.1139253029@sss.pgh.pa.us
Whole thread Raw
In response to Re: slow information schema with thausand users, seq.scan pg_authid  (Andrew - Supernews <andrew+nonews@supernews.com>)
Responses Re: slow information schema with thausand users, seq.scan pg_authid
List 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 by date:

Previous
From: Josh Berkus
Date:
Subject: Re: Copy From & Insert UNLESS
Next
From: Stephan Szabo
Date:
Subject: Re: Copy From & Insert UNLESS