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

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. It's solution explain analyze SELECT n.nspname as "Schema", c.relname as "Name", CASE c.relkind WHEN 'r' THEN 'table' WHEN 'v' THEN 'view' WHEN 'i' THEN 'inde

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

Andrew - Supernews <[EMAIL PROTECTED]> writes: > On 2006-02-06, Peter Eisentraut <[EMAIL PROTECTED]> 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 rath

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

Peter Eisentraut <[EMAIL PROTECTED]> writes: > Andrew - Supernews wrote: >> Perhaps you missed the fact that the query was not one that he wrote, >> but is the query that psql uses for \ds ? > I did miss that. Perhaps with dependency tracking and all, we don't > need the left joins anymore? I d

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

Andrew - Supernews wrote: > Perhaps you missed the fact that the query was not one that he wrote, > but is the query that psql uses for \ds ? I did miss that. Perhaps with dependency tracking and all, we don't need the left joins anymore? -- Peter Eisentraut http://developer.postgresql.org/~pe

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

On 2006-02-06, Peter Eisentraut <[EMAIL PROTECTED]> wrote: > I suggest that your problem is the join order (unless you have 50 > tables as well). Moreover, using left joins instead of inner joins > seems to be quite useless unless you plan to have tables that are not > owned by anyone and a

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

Pavel Stehule wrote: > I know so db 500 000 users isn't normal situation, but I need it. > After user's generation all selects on system's catalog are slow. For > example: list of sequences > > SELECT n.nspname as "Schema", > c.relname as "Name", > CASE c.relkind WHEN 'r' THEN 'table' WHEN 'v'

[HACKERS] slow information schema with thausand users, seq.scan pg_authid

Hello, I know so db 500 000 users isn't normal situation, but I need it. After user's generation all selects on system's catalog are slow. For example: list of sequences SELECT n.nspname as "Schema", c.relname as "Name", CASE c.relkind WHEN 'r' THEN 'table' WHEN 'v' THEN 'view' WHEN 'i' THE