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

From Heikki Linnakangas
Subject Re: GIN improvements part 1: additional information
Date
Msg-id 52DFFFD0.6020708@vmware.com
Whole thread Raw
In response to Re: GIN improvements part 1: additional information  (Alexander Korotkov <aekorotkov@gmail.com>)
Responses Re: GIN improvements part 1: additional information
List pgsql-hackers
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



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Incorrectly reporting config errors
Next
From: Robert Haas
Date:
Subject: Re: dynamic shared memory and locks