On Sun, 20 Nov 2005, Tom Lane wrote:
> Heikki Linnakangas <hlinnaka@iki.fi> writes:
>> 5. Don't try to write buffers with commit hint modifications. Just discard
>> them.
>
> The performance costs of that alone are astonishing (ie, repeated
> verifications of commit status).
You'd vacuum first to avoid that, of course.
> I think what you are doing is a completely wrongheaded way to approach
> it... it sounds incredibly invasive, messy, and fragile. A database or
> tablespace that has been frozen (per VACUUM FREEZE) could sensibly be
> put on read-only media, but I can't see doing the rest of this. Have
> you thought about putting the more dynamic stuff onto a RAM disk?
Invasive: Most of the changes are small modifications to startup and
shutdown routines. I wouldn't call it too invasive. Probably less invasive
than enforcing that a tablespace is read-only, which would be a nice
feature of it's own.
Messy: Well, I guess it's in the eye of the beholder. It depends a lot on
the implementation details.
Fragile: It's certainly something you have to keep in mind whenever you
need to write something to disk. There's not that many places that do
that, I enumerated them in the original mail.
Using a RAM disk is harder for the user. You need to set up the RAM disk,
figure out what to copy to RAM disk and what not, and then be careful not
to change anything that's on the frozen tablespace.
What would a script look like that setups a RAM disk and runs postgres
from that? It's probably doable, but hard to do in a portable way.
There's also this TODO:
Allow a warm standby system to also allow read-only queries [pitr]
In fact, I was originally thinking of that. I should've mentioned it.
It has the same issues with transactions and WAL as running from
read-only media, so I decided to start with the seemingly easier case.
- Heikki