Should we do full-page write for visibilitymap all the time?
Now, when clear visiblitymap, there is no full-page write for vm
since we don't save buffer info in insert/update/delete's log.
The full-page write is used to protect pages from disk failure. Without it,
1) set vm: the vm bits that should be set to 1 may still be 0
2) clear vm: the vm bits that should be set to 0 may still be 1
Are these true? Or the page is totally unpredictable?
To address the problem in
, should we just clear the vm before the log of insert/update/delete?
This may reduce the performance, is there another solution?
On Fri, Mar 25, 2011 at 6:05 AM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
> On Wed, Mar 23, 2011 at 6:16 AM, Jesper Krogh <jesper(at)krogh(dot)cc> wrote:
> > On 2011-03-22 21:43, Robert Haas wrote:
> >> I took a crack at implementing the first approach described above,
> >> which seems to be by far the simplest idea we've come up with to date.
> >> Patch attached. It doesn't seem to be that complicated, which could
> >> mean either that it's not that complicated or that I'm missing
> >> something. Feel free to point and snicker in the latter case.
> > Looks simple, but there is now benefit...
> Your tests and discussion remind me that I haven't yet seen any tests
> that show that index-only scans would be useful for performance.
> Everyone just seems to be assuming that they make a huge difference,
> and that the difference is practically realisable in a common
> Perhaps that's already been done and I just didn't notice?
> Simon Riggs http://www.2ndQuadrant.com/
> PostgreSQL Development, 24x7 Support, Training & Services
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
In response to
pgsql-hackers by date
|Next:||From: Fujii Masao||Date: 2011-03-30 04:29:14|
|Subject: Re: Additional options for Sync Replication|
|Previous:||From: Jaime Casanova||Date: 2011-03-30 02:53:48|
|Subject: Re: pg_last_xlog_receive_location()|