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.comPostgreSQL Training, Services and Support
