Message-ID: <52792FA4.3010508@vmware.com>
Date: Tue, 05 Nov 2013 19:49:24 +0200
From: Heikki Linnakangas <hlinnakangas@vmware.com>
Organization: VMware
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:17.0) Gecko/20131005 Icedove/17.0.9
MIME-Version: 1.0
To: Alexander Korotkov <aekorotkov@gmail.com>
CC: Tomas Vondra <tv@fuzzy.cz>, pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: GIN improvements part 1: additional information
References: 
 <CAPpHfduxv-iL7aedwPW0W5fXrWGAKfxijWM63_hZujaCRxnmFQ@mail.gmail.com>
 <CAPpHfduQrtC4B+MC9_z3QB8oJsK1Ws-H8ivEsy_cmDnfoJqkeQ@mail.gmail.com>
 <CAPpHfdszEJhSynTPX6=tB3aKq1EA1JXpwx4xiFYM097K7PhQLA@mail.gmail.com>
 <CAPpHfdu8=5spaS7c9mxwH7bNMDR6n378fZCv6c2Y3YM7iE5KiQ@mail.gmail.com>
 <51CEA13C.8040103@vmware.com>
 <CAPpHfdutJEC9+6vWX579afZKzdHKCT2wzDkAEom1XmiXEwF3pw@mail.gmail.com>
 <524E7C3B.7060402@vmware.com> <5250A7A1.2010701@fuzzy.cz>
 <CAPpHfdu5ODt1UB5SSpMHHD6LCB+k_t6XCsLBozZP_dyVm1ieLQ@mail.gmail.com>
 <52546434.1000303@vmware.com> <52548F79.6030407@fuzzy.cz>
 <52569635.5090808@vmware.com>
 <CAPpHfduXkYv4uUHHFrCntNQD=JyB=xQXtutXeY_KYs6CBLJN0w@mail.gmail.com>
 <CAPpHfdvXET0Jk=-oWNGGywMZqbiWML4kg9=GvGY8Yruvbhe4BQ@mail.gmail.com>
In-Reply-To: 
 <CAPpHfdvXET0Jk=-oWNGGywMZqbiWML4kg9=GvGY8Yruvbhe4BQ@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

On 04.11.2013 23:44, Alexander Korotkov wrote:
> On Mon, Oct 21, 2013 at 11:12 PM, Alexander Korotkov
> <aekorotkov@gmail.com>wrote:
>
>> Attached version of patch is debugged. I would like to note that number of
>> bugs was low and it wasn't very hard to debug. I've rerun tests on it. You
>> can see that numbers are improved as the result of your refactoring.
>>
>>           event         |     period
>> -----------------------+-----------------
>>   index_build           | 00:01:45.416822
>>   index_build_recovery  | 00:00:06
>>   index_update          | 00:05:17.263606
>>   index_update_recovery | 00:01:22
>>   search_new            | 00:24:07.706482
>>   search_updated        | 00:26:25.364494
>> (6 rows)
>>
>>       label      | blocks_mark
>> ----------------+-------------
>>   search_new     |   847587636
>>   search_updated |   881210486
>> (2 rows)
>>
>>       label     |   size
>> ---------------+-----------
>>   new           | 419299328
>>   after_updates | 715915264
>> (2 rows)
>>
>> Beside simple bugs, there was a subtle bug in incremental item indexes
>> update. I've added some more comments including ASCII picture about how
>> item indexes are shifted.
>>
>> Now, I'm trying to implement support of old page format. Then we can
>> decide which approach to use.
>>
>
> Attached version of patch has support of old page format. Patch still needs
> more documentation and probably refactoring, but I believe idea is clear
> and it can be reviewed. In the patch I have to revert change of null
> category placement for compatibility with old posting list format.

Thanks, just glanced at this quickly.

If I'm reading the patch correctly, old-style non-compressed posting 
tree leaf pages are not vacuumed at all; that's clearly not right.

I argued earlier that we don't need to handle the case that compressing 
a page makes it larger, so that the existing items don't fit on the page 
anymore. I'm having some second thoughts on that; I didn't take into 
account the fact that the "mini-index" in the new page format takes up 
some space. I think it's still highly unlikely that there isn't enough 
space on a 8k page, but it's not totally crazy with a non-standard small 
page size. So at least that situation needs to be checked for with an 
ereport(), rather than Assert.

To handle splitting a non-compressed page, it seems that you're relying 
on the fact that before splitting, we try to insert, which compresses 
the page. The problem with that is that it's not correctly WAL-logged. 
The split record that follows includes a full copy of both page halves, 
but if the split fails for some reason, e.g you run out of disk space, 
there is no WAL record at all of the the compression. I'd suggest doing 
the compression in the insert phase on a temporary copy of the page, 
leaving the original page untouched if there isn't enough space for the 
insertion to complete. (You could argue that this case can't happen 
because the compression must always create enough space to insert one 
more item. maybe so, but at least there should be an explicit check for 
that.)

- Heikki


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers