Re: GIN improvements part 1: additional information

On Fri, Oct 4, 2013 at 12:37 AM, Alexander Korotkov <aekorotkov(at)gmail(dot)com>wrote:

> On Thu, Oct 3, 2013 at 10:48 PM, Robert Haas <robertmhaas(at)gmail(dot)com>wrote:
>
>> On Thu, Oct 3, 2013 at 2:43 PM, Heikki Linnakangas
>> <hlinnakangas(at)vmware(dot)com> wrote:
>> > It seems we've all but decided that we'll require reindexing GIN
>> indexes in
>> > 9.4.
>>
>> I thought the consensus in Ottawa was strongly against that. I'm not
>> aware that anyone has subsequently changed their position on the
>> topic. Bruce is right to point out that we've done such things before
>> and can therefore do it again, but just because we have the technical
>> means to do it doesn't make it good policy.
>>
>> That having been said, if we do decide to break it...
>>
>> > Let's take the opportunity to change some other annoyances with the
>> > current GIN on-disk format:
>>
>> ...then fixing as much as possible in one go-round is clearly a good plan.
>>
>
> Let's see what options we have at all. I see following:
> 1) Drop support old GIN on-disk format. But users will have to reindex
> after pg_upgrade.
> 2) Insert kluges into GIN to support both old and new formats. So, kluges
> are kluges :) I don't see elegant way to do it for now, because formats are
> very different.
> 3) Upgrade GIN on-disk format in pg_upgrade. However, it would be
> rewriting almost whole index. Is it much better than just reindex?
> 4) Fork GIN2, leave GIN as is. It would lead to much of duplicated code.
> Any other options?
>

I came to idea that I like option #4 more than option #2.
If we try to make new GIN work with old page formats we have to maintain 3
use cases:
1) old GIN with old page format (because of old releases)
2) new GIN with old page format
3) new GIN with new page format

If we create GIN2 we maintain only 2 use cases:
1) old GIN with old page format
2) new GIN with new page format
The code of old GIN would be additional code in 9.4, but not additional
code we maintain. Because we anyway maintain exactly same in old releases.

The problem I see is how to migrate users to GIN2. We can't expect they
read release notes, create GIN2 indexes and drop GIN1 indexes. A lot of
users will still use GIN1, because of they don't care :)
Ideally any new GIN index should be GIN2 and reindex turns GIN1 into GIN2.

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