Message-ID: <52DFFFD0.6020708@vmware.com>
Date: Wed, 22 Jan 2014 19:28:48 +0200
From: Heikki Linnakangas <hlinnakangas@vmware.com>
Organization: VMware
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:17.0) Gecko/20131103 Icedove/17.0.10
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: 
 <CAPpHfdutJEC9+6vWX579afZKzdHKCT2wzDkAEom1XmiXEwF3pw@mail.gmail.com>
 <52AEE445.1060206@vmware.com>
 <CAPpHfdvK3eZr8iQJtp9ax9k80MKRKkPKgqcc0SB1bn+_KVq-Xg@mail.gmail.com>
 <52AF837C.3040201@vmware.com> <52B2F5B0.1030809@vmware.com>
 <52B49C34.8060300@vmware.com>
 <CA+HiwqGO91OEE0ZBa0q2RqFEKm5dy5VzXrf7uoYObw9BCKSEVA@mail.gmail.com>
 <CAPpHfduBDxQ7Tw5bZCCgxmJzNHDRG6eELAuseuCEvKt=dw0Yfw@mail.gmail.com>
 <52D0A947.6050706@fuzzy.cz>
 <CAPpHfdskbPbjWYJhkd-FkZCKEUZd03PRAw05NyT0Hd-jxWOyfg@mail.gmail.com>
 <52D478F2.6070005@fuzzy.cz> <52D5E1BC.3000208@fuzzy.cz>
 <CAPpHfdv9Pheu5atEEUk75f_S1nf6vCoRqge2yUQ1v3xgZ4UP3g@mail.gmail.com>
 <CAPpHfds0A03zwmYdhKUg6s01Vq1p30n01=3c-tct264QTpV--Q@mail.gmail.com>
 <52D9789E.3030202@vmware.com> <52DDD51E.2080408@fuzzy.cz>
 <52DE3F55.80103@vmware.com> <52DEE4BF.6010203@vmware.com>
 <CAPpHfdtk+1s3EYE5LZFQr8Xb2Ms_apt67Dj0jb3uAyZj9m34XA@mail.gmail.com>
 <52DF819E.4070507@vmware.com>
 <CAPpHfdu2QBSFvBs=NqssSt-FeXgxhFzDivkso-fwC3VfiV_5eA@mail.gmail.com>
In-Reply-To: 
 <CAPpHfdu2QBSFvBs=NqssSt-FeXgxhFzDivkso-fwC3VfiV_5eA@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 01/22/2014 02:17 PM, Alexander Korotkov wrote:
> We already spent a lot of time with compression. Now we need to figure out
> the result we want see. I spent quite long time debugging varbyte encoding
> without segments. Finally, it passed very many tests without any problems.
> Now, it is just piece of junk. I'm afraid that we will have to reimplement
> everything from scratch another two or three times because code doesn't
> look perfect. For sure, it's incompatible with getting something into 9.4.

That's a bit harsh :-). But yes, I understand what you're saying. It's 
quite common for large patches like this to be rewritten several times 
before being committed; you just don't know what works best until you've 
tried many designs.

> Remember we have also subsequent fast-scan which is very needed for hstore
> and other application.
> I propose to do final decisions now and concentrate forces on making
> committable patch with these decisions. And don't change these decisions
> even if somebody have idea how to improve code readability in 100 times and
> potential extendability in 1000 times.
> I propose following decisions:
> 1) Leave uncompressed area, allow duplicates in it
> 2) Don't introduce Items on page.

Well, I got the insertions to work now without the uncompressed area, so 
in the spirit of Just Getting This Damn Patch Committed, I'm going to go 
ahead with that. We can add the uncompressed area later if performance 
testing shows it to be necessary. And I agree about the Items on page 
idea - we can come back to that too still in 9.4 timeframe if necessary, 
but probably not.

So, committed. It's the same design as in the most recent patch I 
posted, but with a bunch of bugs fixed, and cleaned up all over. I'm 
going to move to the fast scan patch now, but please do test and review 
the committed version to see if I missed something.

- Heikki


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