From: | Scott Ribe <scott_ribe(at)killerbytes(dot)com> |
---|---|
To: | PFC <lists(at)peufeu(dot)com>, Ron Johnson <ron(dot)l(dot)johnson(at)cox(dot)net>, pgsql-general General <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: why postgresql over other RDBMS |
Date: | 2007-06-03 20:45:34 |
Message-ID: | C288848E.75B9C%scott_ribe@killerbytes.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
> 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.)
--
Scott Ribe
scott_ribe(at)killerbytes(dot)com
http://www.killerbytes.com/
(303) 722-0567 voice
From | Date | Subject | |
---|---|---|---|
Next Message | Alexander Staubo | 2007-06-03 20:54:47 | Re: multimaster |
Previous Message | Alexander Staubo | 2007-06-03 20:30:29 | Re: NULLS and User Input WAS Re: multimaster |