Re: why postgresql over other RDBMS
От | PFC |
---|---|
Тема | Re: why postgresql over other RDBMS |
Дата | |
Msg-id | op.ttdanaqgcigqcu@apollo13 обсуждение исходный текст |
Ответ на | Re: why postgresql over other RDBMS (Scott Ribe <scott_ribe@killerbytes.com>) |
Список | pgsql-general |
I believe you have made quite a good description of what happens. Index-building isn't very CPU-intensive for integers (geometrics and tsearch is another matter, of course), so building all indexes of a large table in one pass is a possibility that works now, provided you issue all create index commands in concurrent connections at roughly the same time. I don't think pgrestore does this, though. >> So it works right now, except it doesn't have (yet) the infrastructure >> to >> keep the scans synchronized > > Perhaps you only got one read of the table because the process is > essentially self-synchronizing. Whenever one process "gets ahead", it > requires a disk read for the next page, which causes it to block for a > relatively long time, during which time the other two processes either > proceed reading rows from cache, or come to the end of the cache and > block > waiting for the same page to be read from disk. Obviously not a > guarantee, > as indexing a relatively more expensive type COULD cause one process to > get > multiple pages behind, and memory usage by other processes COULD cause > intervening pages to be flushed from cache. But I have a suspicion that > the > experiment was not just a happy fluke, that there will be a strong > tendency > for multiple simultaneous index operations to stay sufficiently closely > synch'd that the table will only be read from disk once. (Especially when > such operations are done while the database is otherwise quiescent, as > would > be the typical case during a restore.) >
В списке pgsql-general по дате отправления: