On Thu, Oct 3, 2013 at 05:24:49PM -0400, Bruce Momjian wrote: > On Thu, Oct 3, 2013 at 02:48:20PM -0400, Robert Haas wrote: > > On Thu, Oct 3, 2013 at 2:43 PM, Heikki Linnakangas > > <hlinnakan...@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... > > Agreed. I was stating only that this is easy for pg_upgrade. One cool > thing is that the upgrades completes, and the indexes are there, but > just marked as invalid until the REINDEX. > > One other point Alexander made is that the new GIN indexes will be > smaller so most people would want the new format in the new cluster > anyway.
I am in Moscow with Alexander and we were discussing GIN pg_upgrade issues. One option we have already discussed was to take the old GIN index code and put it in a separate directory, and call the new GIN index something different, but that got hung up on how users were going to create indexes of the new type. One nice trick would be for the index creation code to check the global variable IsBinaryUpgrade that pg_upgrade sets. If CREATE INDEX ... GIN finds IsBinaryUpgrade set, it should create an (empty) index of type gin-v1/old. If it is not set, it should create a new gin index. This will allow pg_upgrade to work, and allow REINDEX to create a new-type GIN index from an old one. We would need to append "-v1" to the old index directory, system catalog, and function names. We could then remove the old GIN index code in some later major release, and pg_upgrade will then mark the indexes as invalid and create a REINDEX script. This allows users to reindex their GIN indexes over time, but it doesn't lock us into keeping the gin-v1 code around forever. -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. + -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers