Re: [PERFORM] BUG #4919: CREATE USER command slows down system performance

Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
> Tom Lane wrote:
>> 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.)

If we allow the requirements to creep on this, we'll soon find ourselves
either using or reinventing BDB for the flatfiles. Ick.

[ thinks for awhile... ]

In some sense this is a bootstrap problem: what does it take to get to
the point of being able to read pg_database and its indexes? That is
necessarily not dependent on the particular database we want to join.
Maybe we could solve it by having the relcache write a "global" cache
file containing only entries for the global tables, and load that before
we have identified the database we want to join (after which, we'll load
another cache file for the local entries). It would doubtless take some
rearrangement of the backend startup sequence, but it doesn't seem
obviously impossible.

regards, tom lane