Re: GIN improvements part 1: additional information
От | Alexander Korotkov |
---|---|
Тема | Re: GIN improvements part 1: additional information |
Дата | |
Msg-id | CAPpHfdtWLyHUMYvi3Cb-=rtgq4rR-bEaYg=JG91_gdSjWr8ARA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: GIN improvements part 1: additional information (Alexander Korotkov <aekorotkov@gmail.com>) |
Ответы |
Re: GIN improvements part 1: additional information
|
Список | pgsql-hackers |
On Fri, Oct 4, 2013 at 12:37 AM, Alexander Korotkov <aekorotkov@gmail.com> wrote:
------
With best regards,
Alexander Korotkov.
On Thu, Oct 3, 2013 at 10:48 PM, Robert Haas <robertmhaas@gmail.com> wrote:On Thu, Oct 3, 2013 at 2:43 PM, Heikki LinnakangasI thought the consensus in Ottawa was strongly against that. I'm not
<hlinnakangas@vmware.com> wrote:
> It seems we've all but decided that we'll require reindexing GIN indexes in
> 9.4.
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......then fixing as much as possible in one go-round is clearly a good plan.
> Let's take the opportunity to change some other annoyances with the
> current GIN on-disk format: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.
В списке pgsql-hackers по дате отправления: