Re: GIN improvements part 1: additional information - Mailing list pgsql-hackers

From Alexander Korotkov
Subject Re: GIN improvements part 1: additional information
Date
Msg-id CAPpHfdv9RoHM8AAYxcLcHneiJOQC0GwA1QnFf8x255gDsvQW1Q@mail.gmail.com
Whole thread Raw
In response to Re: GIN improvements part 1: additional information  (Heikki Linnakangas <hlinnakangas@vmware.com>)
List pgsql-hackers
On Fri, Jan 24, 2014 at 1:19 PM, Heikki Linnakangas <hlinnakangas@vmware.com> wrote:
On 01/24/2014 10:53 AM, Alexander Korotkov wrote:
OK. What about previous fix in assert?

Ah right, fixed that too now.

Good, now my test-suite passed. Results are so.

Time of operations
         event         |     period      
-----------------------+-----------------
 index_build           | 00:01:45.709546
 index_build_recovery  | 00:00:09
 index_update          | 00:05:45.732214
 index_update_recovery | 00:01:17
 search_new            | 00:24:02.191049
 search_updated        | 00:26:54.122852
(6 rows)

Index sizes
     label     |   size    
---------------+-----------
 new           | 387547136
 after_updates | 610877440
(2 rows) 

Before compression results were following.

Time of operations
         event         |     period      
-----------------------+-----------------
 index_build           | 00:01:51.116722
 index_build_recovery  | 00:00:08
 index_update          | 00:05:12.124758
 index_update_recovery | 00:01:43
 search_new            | 00:23:44.281424
 search_updated        | 00:25:41.96251
(6 rows)

Index sizes
     label     |    size    
---------------+------------
 new           |  884514816
 after_updates | 1595252736
(2 rows)

So, we can see little regression. However, I'm not sure if it's very significant.

------
With best regards,
Alexander Korotkov.  

pgsql-hackers by date:

Previous
From: Dean Rasheed
Date:
Subject: Re: Infinite recursion in row-security based on updatable s.b. views
Next
From: "MauMau"
Date:
Subject: Re: Recovery to backup point