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 <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
