Re: Transactional vs. Read-only (Retrieval) database
От | Samuel J. Sutjiono |
---|---|
Тема | Re: Transactional vs. Read-only (Retrieval) database |
Дата | |
Msg-id | 00ce01c1e231$929619f0$110a010a@headquarters.wcgroup.com обсуждение исходный текст |
Ответ на | Re: Transactional vs. Read-only (Retrieval) database ("Josh Berkus" <josh@agliodbs.com>) |
Ответы |
Re: Transactional vs. Read-only (Retrieval) database
|
Список | pgsql-sql |
Hi Josh, Thank you very much for your input. About managing disk access and memory, do you know how to ensure the "read-only (to do the search on)" tables(i.e. product catalog) loaded and stay loaded in memory (provided buffer size is big enough for those tables) ? Are you familiar with RAMDISK ? On different subject, do you know how to monitor the number of connections in PostgreSQL ? Regards, Samuel ----- Original Message ----- From: "Josh Berkus" <josh@agliodbs.com> To: "Samuel J. Sutjiono" <ssutjiono@wc-group.com>; <pgsql-general@postgresql.org>; <pgsql-sql@postgresql.org> Sent: Thursday, April 11, 2002 7:16 PM Subject: Re: [SQL] Transactional vs. Read-only (Retrieval) database > Sam, > > > I'd like to get some opinions if there are any benefits (i.e. in > > terms of performance) of creating two separate databases, one for > > transactions (insert, update, delete) and the other one is for > > retrieval/search (select). > > No. Not in Postgresql, unless you wanted to get really exotic. Also, > keep in mind that you cannot join tables from seperate databases in > postgresql. > > There are *lots* of performance advantages to be had by managing disk > access and memory carefully. But not through seperate databases. > > -Josh Berkus >
В списке pgsql-sql по дате отправления: