On Thu, Oct 3, 2013 at 2:43 PM, Heikki Linnakangas <hlinnakangas@vmware.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.
