On Thu, 2008-09-11 at 11:38 +0300, Hannu Krosing wrote: > On Thu, 2008-09-11 at 09:24 +0300, Heikki Linnakangas wrote: > > > I like the idea of acquiring snapshots locally in the slave much more. > > As you mentioned, the options there are to defer applying WAL, or cancel > > queries. > > More exotic ways to defer applying WAL include using some smart > filesystems to get per-backend data snapshots, using either > copy-of-write overlay filesystems and filesystem or disk level > snapshots.
That's certainly possible. That would mean we maintain a single consistent viewpoint of the whole database for a period of time. The frozen viewpoint could move forwards by operator command, or we might keep multiple frozen views. We can have a LookasideHash table in memory that keeps track of which blocks have had rows removed from them since the "frozen view" was taken. If you request a block, we check to see whether there is a lookaside copy of it prior to the tuple removals. We then redirect the block request to a viewpoint relation's block. Each viewpoint gets a separate relfilenode. We do the switcheroo while holding cleanup lock on block. So effectively we would be adding "frozen snapshot" technology to Postgres. Although we would want to do, copy-on-clean rather than copy-on-write. Which could mean significantly better performance. That might be encumbered by patent in some way. -- Simon Riggs www.2ndQuadrant.com PostgreSQL Training, Services and Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
