On Sun, 20 Nov 2005, Tom Lane wrote:
Heikki Linnakangas <[EMAIL PROTECTED]> 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
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
