Re: [WIP] In-place upgrade

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: [WIP] In-place upgrade
Дата
Msg-id 603c8f070811041257m60df429ct40694f509b876829@mail.gmail.com
обсуждение исходный текст
Ответ на [WIP] In-place upgrade  (Zdenek Kotala <Zdenek.Kotala@Sun.COM>)
Ответы Re: [WIP] In-place upgrade  (Gregory Stark <stark@enterprisedb.com>)
Список pgsql-hackers
>> Well, I just proposed an approach that doesn't work this way, so I
>> guess I'll have to put myself in the disagree category, or anyway yet
>> to be convinced.  As long as you can move individual tuples onto new
>> pages, you can eventually empty V3 pages and reinitialize them as new,
>> empty V4 pages.  You can force that process along via, say, VACUUM,
>
> No, if you can force that process along via some command, whatever it is, then
> you're still in the category he described.

Maybe.  The difference is that I'm talking about converting tuples,
not pages, so "What happens when the data doesn't fit on the new
page?" is a meaningless question.  Since that seemed to be Heikki's
main concern, I thought we must be talking about different things.  My
thought was that the code path for converting a tuple would be very
similar to what heap_update does today, and large tuples would be
handled via TOAST just as they are now - by converting the relation
one tuple at a time, you might end up with a new relation that has
either more or fewer pages than the old relation, and it really
doesn't matter which.

I haven't really thought through all of the other kinds of things that
might need to be converted, though.  That's where it would be useful
for someone more experienced to weigh in on indexes, etc.

...Robert


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: BufferAccessStrategy for bulk insert
Следующее
От: Tom Lane
Дата:
Сообщение: Re: [PATCH] Cleanup of PLpgSQL_recfield