Re: GIN improvements part 1: additional information

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Alexander Korotkov <aekorotkov(at)gmail(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: GIN improvements part 1: additional information
Date: 2013-10-04 02:56:23
Message-ID: 20131004025623.GA14622@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Oct 4, 2013 at 02:23:33AM +0400, Alexander Korotkov wrote:
> 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.

I am not sure I like the complexity of a GIN2, but we should give this
problem some serious thought as it will affect how we deal with other
on-disk index changes in the future.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2013-10-04 04:10:38 Re: Suggestion: Issue warning when calling SET TRANSACTION outside transaction block
Previous Message Peter Geoghegan 2013-10-04 02:01:30 Re: Any reasons to not move pgstattuple to core?