Re: Transaction Snapshots and Hot Standby

From: Hannu Krosing <hannu(at)2ndQuadrant(dot)com>
To: Csaba Nagy <nagy(at)ecircle-ag(dot)com>
Cc: Simon Riggs <simon(at)2ndQuadrant(dot)com>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Transaction Snapshots and Hot Standby
Date: 2008-09-12 09:30:33
Message-ID: 1221211833.7026.9.camel@huvostro
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, 2008-09-12 at 11:21 +0200, Csaba Nagy wrote:
> On Fri, 2008-09-12 at 09:38 +0100, Simon Riggs wrote:
> > 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.
>
> Wouldn't it make sense to also have a hint bit on the pages which are
> copied away ?

There is no need for hint bit (and one bit would not be enough anyway,
as we may need to keep multiple versions)

A LSN of last row-removal (VACUUM or HOT-pruning) would serve as a hint
to start digging around in hash tables.

It seems though , that you may have to look into several disk snapshots
to find the page you need.

> Then instead of looking up a hash table, you first would
> look up that bit, and if not set you won't look up the hash table at
> all. Then when you clean up the "lookaside copies" you clear those bits
> too...
>
> That would probably perform somewhat better for reading than always
> looking up a potentially big hash table, and the cost of setting the
> hint is probably a lot less than copying away the page in the first
> place. Resetting the hint bit might be a bit more expensive.
>
> Cheers,
> Csaba.
>
>

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Heikki Linnakangas 2008-09-12 09:40:58 Re: New FSM patch
Previous Message Magnus Hagander 2008-09-12 09:29:38 Re: Parsing of pg_hba.conf and authentication inconsistencies