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