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. -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
