| From: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
|---|---|
| To: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
| Cc: | pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Summary and Plan for Hot Standby |
| Date: | 2009-11-15 17:53:45 |
| Message-ID: | 1258307625.14054.2189.camel@ebony |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Sun, 2009-11-15 at 19:36 +0200, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > On Sun, 2009-11-15 at 16:07 +0200, Heikki Linnakangas wrote:
> >
> >> The assumption that b-tree vacuum records don't need conflict
> >> resolution because we did that with the additional cleanup-info record
> >> works ATM, but it hinges on the fact that we don't delete any tuples
> >> marked as killed while we do the vacuum.
> >
> >> That seems like a low-hanging
> >> fruit that I'd actually like to do now that I spotted it, but will
> >> then need to fix b-tree vacuum records accordingly. We'd probably need
> >> to do something about the previous item first to keep performance
> >> acceptable.
> >
> > We can optimise that by using the xlog pointer of the HeapInfo record.
> > Any blocks cleaned that haven't been further updated can avoid
> > generating further btree deletion records.
>
> Sorry, I don't understand that. (Remember that marking index tuples as
> killed is not WAL-logged.)
Remember that blocks are marked with an LSN? When we insert a WAL record
it has an LSN also. So we can tell which btree blocks might have had
been written to after the HeapInfo record is generated. So if a block
hasn't been recently updated or it doesn't have any killed tuples then
we need not generate a record to handle a possible conflict.
--
Simon Riggs www.2ndQuadrant.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Pavel Stehule | 2009-11-15 17:54:08 | Re: named parameters in SQL functions |
| Previous Message | Pavel Stehule | 2009-11-15 17:51:53 | Re: named parameters in SQL functions |