Re: crash-safe visibility map, take four
| От | 高增琦 |
|---|---|
| Тема | Re: crash-safe visibility map, take four |
| Дата | |
| Msg-id | AANLkTik5V28HAGmKq0oX5K-HhKinB6BSHmN93EEa3Hu7@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: crash-safe visibility map, take four (Simon Riggs <simon@2ndQuadrant.com>) |
| Ответы |
Re: crash-safe visibility map, take four
|
| Список | pgsql-hackers |
Hi,
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?
Another question:
To address the problem in
Thanks.
--
GaoZengqi
pgf00a@gmail.com
zengqigao@gmail.com
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?
Another question:
To address the problem in
http://archives.postgresql.org/pgsql-hackers/2010-02/msg02097.php
, should we just clear the vm before the log of insert/update/delete?
This may reduce the performance, is there another solution?
, should we just clear the vm before the log of insert/update/delete?
This may reduce the performance, is there another solution?
Thanks.
--
GaoZengqi
pgf00a@gmail.com
zengqigao@gmail.com
On Fri, Mar 25, 2011 at 6:05 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
On Wed, Mar 23, 2011 at 6:16 AM, Jesper Krogh <jesper@krogh.cc> wrote:> On 2011-03-22 21:43, Robert Haas wrote:> Looks simple, but there is now benefit...
>>
>> 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.
>
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
workload.
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@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
В списке pgsql-hackers по дате отправления: