Re: [HACKERS] Proposal: Multiversion page api (inplace upgrade)

2008-06-13 Thread Tom Lane
Zdenek Kotala <[EMAIL PROTECTED]> writes: > It does not solve problems for example with TOAST tables. If chunks does not > fit > on a new page layout one of the chunk tuple have to be moved to free page. It > means you get a lot of pages with ~2kB of free unused space. And if max chunk > size i

Re: [HACKERS] Proposal: Multiversion page api (inplace upgrade)

2008-06-13 Thread Zdenek Kotala
Bruce Momjian napsal(a): Heikki Linnakangas wrote: Zdenek Kotala wrote: 4) Implementation The main point of implementation is to have several version of PageHeader structure (e.g. PageHeader_04, PageHeader_03 ...) and correct structure will be handled in special branch (see examples). (this

Re: [HACKERS] Proposal: Multiversion page api (inplace upgrade)

2008-06-13 Thread Zdenek Kotala
Ron Mayer napsal(a): Tom Lane wrote: Another issue is that it might not be possible to update a page for lack of space. Are we prepared to assume that there will never be a transformation we need to apply that makes the data bigger? In such a situation an in-place update might be impossible,

Re: [HACKERS] Proposal: Multiversion page api (inplace upgrade)

2008-06-12 Thread Ron Mayer
Tom Lane wrote: Another issue is that it might not be possible to update a page for lack of space. Are we prepared to assume that there will never be a transformation we need to apply that makes the data bigger? In such a situation an in-place update might be impossible, and that certainly tak

Re: [HACKERS] Proposal: Multiversion page api (inplace upgrade)

2008-06-12 Thread Decibel!
On Jun 11, 2008, at 10:42 AM, Heikki Linnakangas wrote: Another issue is that it might not be possible to update a page for lack of space. Are we prepared to assume that there will never be a transformation we need to apply that makes the data bigger? We do need some solution to that. One ide

Re: [HACKERS] Proposal: Multiversion page api (inplace upgrade)

2008-06-12 Thread Bruce Momjian
Heikki Linnakangas wrote: > Zdenek Kotala wrote: > > 4) Implementation > > > > The main point of implementation is to have several version of > > PageHeader structure (e.g. PageHeader_04, PageHeader_03 ...) and correct > > structure will be handled in special branch (see examples). > > (this wo

Re: [HACKERS] Proposal: Multiversion page api (inplace upgrade)

2008-06-11 Thread Stephen Denne
Gregory Stark wrote: > "Tom Lane" <[EMAIL PROTECTED]> writes: > > > (Likely counterexample: adding collation info to text values.) > > I don't think the argument really needs an example, but I > would be pretty > upset if we proposed tagging every text datum with a > collation. Encoding > perha

Re: [HACKERS] Proposal: Multiversion page api (inplace upgrade)

2008-06-11 Thread Gregory Stark
"Tom Lane" <[EMAIL PROTECTED]> writes: > (Likely counterexample: adding collation info to text values.) I don't think the argument really needs an example, but I would be pretty upset if we proposed tagging every text datum with a collation. Encoding perhaps, though that seems like a bad idea to

Re: [HACKERS] Proposal: Multiversion page api (inplace upgrade)

2008-06-11 Thread Zdenek Kotala
Heikki Linnakangas napsal(a): Tom Lane wrote: "Heikki Linnakangas" <[EMAIL PROTECTED]> writes: (this won't come as a surprise as we talked about this in PGCon, but) I think we should rather convert the page structure to new format in ReadBuffer the first time a page is read in. That would keep

Re: [HACKERS] Proposal: Multiversion page api (inplace upgrade)

2008-06-11 Thread Zdenek Kotala
Heikki Linnakangas napsal(a): Zdenek Kotala wrote: 4) Implementation The main point of implementation is to have several version of PageHeader structure (e.g. PageHeader_04, PageHeader_03 ...) and correct structure will be handled in special branch (see examples). (this won't come as a surp

Re: [HACKERS] Proposal: Multiversion page api (inplace upgrade)

2008-06-11 Thread Heikki Linnakangas
Tom Lane wrote: "Heikki Linnakangas" <[EMAIL PROTECTED]> writes: (this won't come as a surprise as we talked about this in PGCon, but) I think we should rather convert the page structure to new format in ReadBuffer the first time a page is read in. That would keep the changes a lot more isolat

Re: [HACKERS] Proposal: Multiversion page api (inplace upgrade)

2008-06-11 Thread Zdenek Kotala
Tom Lane napsal(a): Zdenek Kotala <[EMAIL PROTECTED]> writes: There are examples: void PageSetFull(Page page) { switch ( PageGetPageLayoutVersion(page) ) { case 4 : ((PageHeader_04) (page))->pd_flags |= PD_PAGE_FULL; break;

Re: [HACKERS] Proposal: Multiversion page api (inplace upgrade)

2008-06-11 Thread Tom Lane
"Heikki Linnakangas" <[EMAIL PROTECTED]> writes: > (this won't come as a surprise as we talked about this in PGCon, but) I > think we should rather convert the page structure to new format in > ReadBuffer the first time a page is read in. That would keep the changes > a lot more isolated. The p

Re: [HACKERS] Proposal: Multiversion page api (inplace upgrade)

2008-06-11 Thread Heikki Linnakangas
Zdenek Kotala wrote: 4) Implementation The main point of implementation is to have several version of PageHeader structure (e.g. PageHeader_04, PageHeader_03 ...) and correct structure will be handled in special branch (see examples). (this won't come as a surprise as we talked about this in

Re: [HACKERS] Proposal: Multiversion page api (inplace upgrade)

2008-06-11 Thread Tom Lane
Zdenek Kotala <[EMAIL PROTECTED]> writes: > There are examples: > void PageSetFull(Page page) > { > switch ( PageGetPageLayoutVersion(page) ) > { > case 4 : ((PageHeader_04) (page))->pd_flags |= PD_PAGE_FULL; > break; > defaul

[HACKERS] Proposal: Multiversion page api (inplace upgrade)

2008-06-11 Thread Zdenek Kotala
1) Overview This proposal is part of inplace upgrade project. PostgreSQL should be able to read any page in old version. This is basic for all possible upgrade method. 2) Background We have several macros for manipulating of the page structures but this list is not complete and many parts o