Re: [WIP] In-place upgrade - Mailing list pgsql-hackers

From Robert Haas
Subject Re: [WIP] In-place upgrade
Date
Msg-id 603c8f070811041257m60df429ct40694f509b876829@mail.gmail.com
Whole thread Raw
In response to [WIP] In-place upgrade  (Zdenek Kotala <Zdenek.Kotala@Sun.COM>)
Responses Re: [WIP] In-place upgrade  (Gregory Stark <stark@enterprisedb.com>)
List 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 by date:

Previous
From: Tom Lane
Date:
Subject: Re: BufferAccessStrategy for bulk insert
Next
From: Tom Lane
Date:
Subject: Re: [PATCH] Cleanup of PLpgSQL_recfield