Re: ROLAP (was Re: A test to add to the crashme test)
От | Ross J. Reedstrom |
---|---|
Тема | Re: ROLAP (was Re: A test to add to the crashme test) |
Дата | |
Msg-id | 20000523093315.A5814@rice.edu обсуждение исходный текст |
Ответ на | ROLAP (was Re: A test to add to the crashme test) (Michael Robinson <robinson@netrinsics.com>) |
Список | pgsql-hackers |
On Tue, May 23, 2000 at 12:36:16PM +0800, Michael Robinson wrote: > "Ross J. Reedstrom" <reedstrm@wallace.ece.rice.edu> writes: > >On Mon, May 22, 2000 at 03:46:39PM +0800, Michael Robinson wrote: > >> MySQL is extremely well suited for it: the data is essentially "read-only" > >> so transactions, locking, etc., are not an issue, > > > >People keep claiming that applications that are essentially "read-only" > >don't need transactions. I'll agree in the limit, that truly read only > >databases don't, but I think a lot of people might be surprised at how > >little writing you need before you get into trouble. > > Very true. However, if you can guarantee that there is only ever one > writer (e.g., a batch process), and you don't mind the occasional dirty > read, you don't need any locking at all. Right - my whole diatribe was actually about locking. And the case you describe is what I meant by "in the limit, [a] truly read only database" If all your writing is planned, controlled, batch updates, fine. But my point stands: you only need _one_ ad hoc writer to potentially get you into trouble, with all the messiness of lock contention, etc. The work arounds mozilla.org were looking at to fix this problem involve keeping multiple databases and syncing periodically, or lower the priority of INSERTS (!): they looked like treating the symptom, rather that addressing the problem, to me. Ross -- Ross J. Reedstrom, Ph.D., <reedstrm@rice.edu> NSBRI Research Scientist/Programmer Computer and Information Technology Institute Rice University, 6100 S. Main St., Houston, TX 77005
В списке pgsql-hackers по дате отправления: