Re: why postgresql over other RDBMS

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

In response to

Responses

Browse pgsql-general by date

  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