Re: Freeze avoidance of very large table. - Mailing list pgsql-hackers

From Fujii Masao
Subject Re: Freeze avoidance of very large table.
Date
Msg-id CAHGQGwERPM+gmyx=q8Yjck2nWEz0-buBSgjAXB_CptAz=bacPg@mail.gmail.com
Whole thread Raw
In response to Re: Freeze avoidance of very large table.  (Sawada Masahiko <sawada.mshk@gmail.com>)
Responses Re: Freeze avoidance of very large table.
List pgsql-hackers
On Thu, Jul 2, 2015 at 12:13 AM, Sawada Masahiko <sawada.mshk@gmail.com> wrote:
> On Thu, May 28, 2015 at 11:34 AM, Sawada Masahiko <sawada.mshk@gmail.com> wrote:
>> On Thu, Apr 30, 2015 at 8:07 PM, Sawada Masahiko <sawada.mshk@gmail.com> wrote:
>>> On Fri, Apr 24, 2015 at 11:21 AM, Sawada Masahiko <sawada.mshk@gmail.com> wrote:
>>>> On Fri, Apr 24, 2015 at 1:31 AM, Jim Nasby <Jim.Nasby@bluetreble.com> wrote:
>>>>> On 4/23/15 11:06 AM, Petr Jelinek wrote:
>>>>>>
>>>>>> On 23/04/15 17:45, Bruce Momjian wrote:
>>>>>>>
>>>>>>> On Thu, Apr 23, 2015 at 09:45:38AM -0400, Robert Haas wrote:
>>>>>>> Agreed, no extra file, and the same write volume as currently.  It would
>>>>>>> also match pg_clog, which uses two bits per transaction --- maybe we can
>>>>>>> reuse some of that code.
>>>>>>>
>>>>>>
>>>>>> Yeah, this approach seems promising. We probably can't reuse code from
>>>>>> clog because the usage pattern is different (key for clog is xid, while
>>>>>> for visibility/freeze map ctid is used). But visibility map storage
>>>>>> layer is pretty simple so it should be easy to extend it for this use.
>>>>>
>>>>>
>>>>> Actually, there may be some bit manipulation functions we could reuse;
>>>>> things like efficiently counting how many things in a byte are set. Probably
>>>>> doesn't make sense to fully refactor it, but at least CLOG is a good source
>>>>> for cut/paste/whack.
>>>>>
>>>>
>>>> I agree with adding a bit that indicates corresponding page is
>>>> all-frozen into VM, just like CLOG.
>>>> I'll change the patch as second version patch.
>>>>
>>>
>>> The second patch is attached.
>>>
>>> In second patch, I added a bit that indicates all tuples in page are
>>> completely frozen into visibility map.
>>> The visibility map became a bitmap with two bit per heap page:
>>> all-visible and all-frozen.
>>> The logics around vacuum, insert/update/delete heap are almost same as
>>> previous version.
>>>
>>> This patch lack some point: documentation, comment in source code,
>>> etc, so it's WIP patch yet,
>>> but I think that it's enough to discuss about this.
>>>
>>
>> The previous patch is no longer applied cleanly to HEAD.
>> The attached v2 patch is latest version.
>>
>> Please review it.
>
> Attached new rebased version patch.
> Please give me comments!

Now we should review your design and approach rather than code,
but since I got an assertion error while trying the patch, I report it.

"initdb -D test -k" caused the following assertion failure.

vacuuming database template1 ... TRAP:
FailedAssertion("!((((PageHeader) (heapPage))->pd_flags & 0x0004))",
File: "visibilitymap.c", Line: 328)
sh: line 1: 83785 Abort trap: 6
"/dav/000_add_frozen_bit_into_visibilitymap_v3/bin/postgres" --single
-F -O -c search_path=pg_catalog -c exit_on_error=true template1 >
/dev/null
child process exited with exit code 134
initdb: removing data directory "test"

Regards,

-- 
Fujii Masao



pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: Macro nesting hell
Next
From: Andres Freund
Date:
Subject: Raising our compiler requirements for 9.6