I wrote:
> Alvaro Herrera <alvherre@commandprompt.com> 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
