From: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
---|---|
To: | "John D(dot) Burger" <john(at)mitre(dot)org> |
Cc: | "pgsql-general postgresql(dot)org" <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Limit on number of users in postgresql? |
Date: | 2007-01-29 19:38:32 |
Message-ID: | 20070129193832.GC14134@alvh.no-ip.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
John D. Burger wrote:
> Tom Lane wrote:
>
> >>What you describe Tom (flat file), sounds a bit strange to me.
> >>Aren't users
> >>stored in a table? (pg_catalog.pg_authid)
> >
> >Yeah, but the postmaster can't read pg_authid, nor any other table,
> >because it's not logically connected to the database. So any change
> >to pg_authid gets copied to a "flat" ASCII-text file for the
> >postmaster.
>
> Why doesn't the postmaster read the db files directly, presumably
> using some of the same code the backends do, or is too hard to bypass
> the shared memory layer?
We used to do that, and we're lucky that it was replaced by the current
plaintext file mechanism, because it was ugly and very limited. And
probably slow too.
> Another thing you folks must have
> considered would be to keep the out-of-memory copies of this kind of
> data in something faster than a flat file - say Berkeley DB. Do
> either of these things make sense?
I don't know a lot about BerkeleyDB, but I'm sure that if plain files
were proven to be a bottleneck we could hack some sort of indexed
storage. Making BDB or something similar a hard requirement is
certainly out of the question. On the other hand, writing such a thing
would probably be more costly than writing a plaintext file ...
--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2007-01-29 19:48:38 | Re: Limit on number of users in postgresql? |
Previous Message | shakahshakah@gmail.com | 2007-01-29 19:36:17 | VACUUM ANALYZE taking a long time, %I/O and %CPU very low |