Re: [HACKERS] PGUpgrade WAS: Audio interview
От
Tom Lane
Тема
Re: [HACKERS] PGUpgrade WAS: Audio interview
Дата
Msg-id
16817.1139431868@sss.pgh.pa.us
Ответ на
Re: [pgsql-advocacy] PGUpgrade WAS: Audio interview (Josh Berkus)
Список
Дерево обсуждения
Audio interview Bruce Momjian <pgman@candle.pha.pa.us>
Re: Audio interview Robert Bernier <robert.bernier5@sympatico.ca>
Re: Audio interview David Fetter <david@fetter.org>
Re: Audio interview Bruce Momjian <pgman@candle.pha.pa.us>
Re: Audio interview David Fetter <david@fetter.org>
Re: Audio interview Bruce Momjian <pgman@candle.pha.pa.us>
Re: [HACKERS] Audio interview Andrew Dunstan <andrew@dunslane.net>
Re: [HACKERS] PGUpgrade WAS: Audio interview Josh Berkus <josh@agliodbs.com>
Re: [HACKERS] PGUpgrade WAS: Audio interview Rick Gigger <rick@alpinenetworking.com>
Re: [HACKERS] PGUpgrade WAS: Audio interview Neil Conway <neilc@samurai.com>
Re: [HACKERS] PGUpgrade WAS: Audio interview Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] PGUpgrade WAS: Audio interview Hannu Krosing <hannu@skype.net>
Re: [HACKERS] PGUpgrade WAS: Audio interview Jeff Davis <pgsql@j-davis.com>
Re: [HACKERS] PGUpgrade WAS: Audio interview Alvaro Herrera <alvherre@commandprompt.com>
Re: [HACKERS] PGUpgrade WAS: Audio interview Josh Berkus <josh@agliodbs.com>
Re: [HACKERS] Audio interview Rick Gigger <rick@alpinenetworking.com>
Josh Berkus writes: >> This would be a very fine project for someone to pick up (maybe one of >> the corporate supporters could sponsor someone to work on it?) > We looked at it for Greenplum but just couldn't justify putting it near > the top of the priority list. The work/payoff ratio is terrible. I agree that doing pgupgrade in full generality is probably not worth the investment required. However, handling the restricted case where no changes are needed in user tables or indexes would be considerably easier, and I think it would be worth doing. If such a tool were available, I don't think it'd be hard to get consensus on organizing our releases so that it were applicable more often than not. We could postpone changes that would affect user table contents until we'd built up a backlog that would all go into one release. Even a minimal commitment in that line would probably result in pgupgrade working for at least every other release, and that would be enough to make it worthwhile if you ask me ... regards, tom lane
В списке pgsql-advocacy по дате отправления