I wrote: > Alvaro Herrera <alvherre@xxxxxxxxxxxxxxxxx> writes: >> Tom Lane wrote: >>> ... I don't remember exactly what we do with the >>> flat-file contents. >> Maybe what we need is not to get rid of the flat files, but to speed >> them up. If we're worried about speed in the pg_authid flatfile, and >> come up with a solution to that problem, what will we do with the >> pg_database flatfile when it grows too large? We can't just get rid of >> it, because autovacuum needs to access it. > Well, one of the components of the TODO would have to be to figure out a > way to fix autovacuum to avoid that. 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. 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...) regards, tom lane -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
