"Pavan Deolasee" <pavan.deolasee@gmail.com> writes:
> I am not suggesting one read-write and many read-only architecture. I am
> rather suggesting all read-only systems. I would be interested in this
> setup if I run large read-only queries on historical data and need easy
> scalability. With read-only setup, you can easily add another machine to
> increase computing power.
That's especially attractive if it could be done on a table-by-table basis. So
for example, if you froze all the tuples in a table and marked it read-only
then another database could mount that table be able to perform queries on it.
There are problems around making sure that all the databases mounting the
table are the same architecture and agree about the meanings of all the type
oids.
And I'm not sure how you would ever undo the situation. You would need some
way to indicate the read-only table is "locked" by the other databases so the
master database would know it couldn't be made read-write until they "unlock"
it.
> On Sat, Apr 12, 2008 at 11:00 PM, Dawid Kuroczko <qnex42@gmail.com> wrote:
>> Noow, if you really really want a read-only copy of the read write data
>> available over the network, many NAS/SAN devices will allow you to
>> make a snapshot of the database -- and you can use that snapshot as
>> a read-only copy of the database. But then again, if you want a read-only
>> copy of a days/weeks old database, there are chaper and better ways of
>> doing it.
Actually that's a great way of doing it. I think we're going to run into this
"problem" more and more often, that there are good lower-level solutions to
the same problems we're tackling in the application.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's 24x7 Postgres support!