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-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 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 is

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 won't come as

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

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

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; default

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

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 problem

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 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 isolated.

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

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 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 me

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 perhaps, though