Re: GIN improvements part 1: additional information
| От | Alexander Korotkov |
|---|---|
| Тема | Re: GIN improvements part 1: additional information |
| Дата | |
| Msg-id | CAPpHfdvapv35UzyW02Lqr-20v_+JJy5jaU2Kj=FFSEFULiZ54Q@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: GIN improvements part 1: additional information (Robert Haas <robertmhaas@gmail.com>) |
| Ответы |
Re: GIN improvements part 1: additional information
Re: GIN improvements part 1: additional information |
| Список | pgsql-hackers |
On Thu, Oct 3, 2013 at 10:48 PM, Robert Haas <robertmhaas@gmail.com> wrote:
------
With best regards,
Alexander Korotkov.
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?
With best regards,
Alexander Korotkov.
В списке pgsql-hackers по дате отправления: