Re: GIN improvements part 1: additional information
От | Bruce Momjian |
---|---|
Тема | Re: GIN improvements part 1: additional information |
Дата | |
Msg-id | 20130923153554.GA9534@momjian.us обсуждение исходный текст |
Ответ на | Re: GIN improvements part 1: additional information (Alexander Korotkov <aekorotkov@gmail.com>) |
Ответы |
Re: GIN improvements part 1: additional information
|
Список | pgsql-hackers |
On Sun, Sep 15, 2013 at 01:14:45PM +0400, Alexander Korotkov wrote: > On Sat, Jun 29, 2013 at 12:56 PM, Heikki Linnakangas <hlinnakangas@vmware.com> > wrote: > > There's a few open questions: > > 1. How are we going to handle pg_upgrade? It would be nice to be able to > read the old page format, or convert on-the-fly. OTOH, if it gets too > complicated, might not be worth it. The indexes are much smaller with the > patch, so anyone using GIN probably wants to rebuild them anyway, sooner or > later. Still, I'd like to give it a shot. We have broken pg_upgrade index compatibility in the past. Specifically, hash and GIN index binary format changed from PG 8.3 to 8.4. I handled it by invalidating the indexes and providing a post-upgrade script to REINDEX all the changed indexes. The user message is: Your installation contains hash and/or GIN indexes. These indexes have different internal formats between your oldand new clusters, so they must be reindexed with the REINDEX command. The file: ... when executed by psql by the database superuser will recreate all invalid indexes; until then, none of these indexeswill be used. It would be very easy to do this from a pg_upgrade perspective. However, I know there has been complaints from others about making pg_upgrade more restrictive. In this specific case, even if you write code to read the old file format, we might want to create the REINDEX script to allow _optional_ reindexing to shrink the index files. If we do require the REINDEX, --check will clearly warn the user that this will be required. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
В списке pgsql-hackers по дате отправления: