Tom Lane wrote:
> Actually, I had forgotten that we were using the pg_database flatfile
> for purposes other than authentication checks. In particular, we need
> it during backend startup to map from database name to database OID,
> without which it's impossible to locate the system catalogs for the
> target database. It's pretty hard to see a way around that one.
> We could grovel through pg_database itself, as indeed is done to rebuild
> the flatfile during system start. But that's certainly not going to be
> fast in cases where there are enough DBs to make the flatfile slow.
Also, IIRC flatfiles were introduced precisely to avoid having to read
the catalogs manually.
> So on third thought, Alvaro's right: the only real solution here is to
> adopt a more efficient representation of the flat files. Maybe some
> sort of simple hashtable arrangement would work. (Rendering them not so
> flat anymore...)
As long as there's a simple API, there should be no problem.
(Except that it would be nice to be able to build the file incrementally
... If we have to write out a million lines each time a millionth user
is created, there will still be a bottleneck at CREATE USER time.)
--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
