diff --git a/doc/TODO.detail/drop b/doc/TODO.detail/drop index 4b7c286e5cf2e4b94a63bff88f2a988c168f3f1d..24a4cfebe1edd78a39d1e916c9422843c4873dcd 100644 --- a/doc/TODO.detail/drop +++ b/doc/TODO.detail/drop @@ -2,7 +2,7 @@ From pgsql-hackers-owner+M3040@hub.org Thu Jun 8 00:31:01 2000 Received: from renoir.op.net (root@renoir.op.net [207.29.195.4]) by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id AAA13157 for ; Thu, 8 Jun 2000 00:31:00 -0400 (EDT) -Received: from hub.org (root@hub.org [216.126.84.1]) by renoir.op.net (o1/$Revision: 1.4 $) with ESMTP id AAA01089 for ; Thu, 8 Jun 2000 00:17:19 -0400 (EDT) +Received: from hub.org (root@hub.org [216.126.84.1]) by renoir.op.net (o1/$Revision: 1.5 $) with ESMTP id AAA01089 for ; Thu, 8 Jun 2000 00:17:19 -0400 (EDT) Received: from hub.org (majordom@localhost [127.0.0.1]) by hub.org (8.10.1/8.10.1) with SMTP id e5846ib99782; Thu, 8 Jun 2000 00:06:44 -0400 (EDT) @@ -280,7 +280,7 @@ From Inoue@tpf.co.jp Sat Jun 10 01:01:01 2000 Received: from renoir.op.net (root@renoir.op.net [207.29.195.4]) by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id BAA10355 for ; Sat, 10 Jun 2000 01:01:00 -0400 (EDT) -Received: from sd.tpf.co.jp (sd.tpf.co.jp [210.161.239.34]) by renoir.op.net (o1/$Revision: 1.4 $) with ESMTP id AAA25467 for ; Sat, 10 Jun 2000 00:41:32 -0400 (EDT) +Received: from sd.tpf.co.jp (sd.tpf.co.jp [210.161.239.34]) by renoir.op.net (o1/$Revision: 1.5 $) with ESMTP id AAA25467 for ; Sat, 10 Jun 2000 00:41:32 -0400 (EDT) Received: from mcadnote1 (ppm110.noc.fukui.nsk.ne.jp [210.161.188.29] (may be forged)) by sd.tpf.co.jp (2.5 Build 2640 (Berkeley 8.8.6)/8.8.4) with SMTP id NAA03125; Sat, 10 Jun 2000 13:40:40 +0900 @@ -411,7 +411,7 @@ From tgl@sss.pgh.pa.us Sat Jun 10 01:31:04 2000 Received: from renoir.op.net (root@renoir.op.net [207.29.195.4]) by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id BAA10922 for ; Sat, 10 Jun 2000 01:31:03 -0400 (EDT) -Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2]) by renoir.op.net (o1/$Revision: 1.4 $) with ESMTP id BAA27265 for ; Sat, 10 Jun 2000 01:16:07 -0400 (EDT) +Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2]) by renoir.op.net (o1/$Revision: 1.5 $) with ESMTP id BAA27265 for ; Sat, 10 Jun 2000 01:16:07 -0400 (EDT) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id BAA06206; Sat, 10 Jun 2000 01:14:37 -0400 (EDT) @@ -457,7 +457,7 @@ From dhogaza@pacifier.com Sat Jun 10 09:30:59 2000 Received: from renoir.op.net (root@renoir.op.net [207.29.195.4]) by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id JAA25987 for ; Sat, 10 Jun 2000 09:30:58 -0400 (EDT) -Received: from smtp.pacifier.com (comet.pacifier.com [199.2.117.155]) by renoir.op.net (o1/$Revision: 1.4 $) with ESMTP id JAA18716 for ; Sat, 10 Jun 2000 09:15:08 -0400 (EDT) +Received: from smtp.pacifier.com (comet.pacifier.com [199.2.117.155]) by renoir.op.net (o1/$Revision: 1.5 $) with ESMTP id JAA18716 for ; Sat, 10 Jun 2000 09:15:08 -0400 (EDT) Received: from desktop (dsl-dhogaza.pacifier.net [207.202.226.68]) by smtp.pacifier.com (8.9.3/8.9.3pop) with SMTP id GAA15799; Sat, 10 Jun 2000 06:14:28 -0700 (PDT) @@ -509,7 +509,7 @@ From tgl@sss.pgh.pa.us Sun Jun 11 12:31:03 2000 Received: from renoir.op.net (root@renoir.op.net [207.29.195.4]) by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id MAA05771 for ; Sun, 11 Jun 2000 12:31:01 -0400 (EDT) -Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2]) by renoir.op.net (o1/$Revision: 1.4 $) with ESMTP id MAA19315 for ; Sun, 11 Jun 2000 12:24:06 -0400 (EDT) +Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2]) by renoir.op.net (o1/$Revision: 1.5 $) with ESMTP id MAA19315 for ; Sun, 11 Jun 2000 12:24:06 -0400 (EDT) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id MAA09503; Sun, 11 Jun 2000 12:22:42 -0400 (EDT) @@ -930,3 +930,934 @@ Hiroshi Inoue TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to majordomo@postgresql.org) +From chriskl@familyhealth.com.au Thu Apr 11 12:00:22 2002 +Return-path: +Received: from houston.familyhealth.com.au (root@i231-006.nv.iinet.net.au [203.59.231.6]) + by candle.pha.pa.us (8.11.6/8.10.1) with ESMTP id g3BG0KS02910 + for ; Thu, 11 Apr 2002 12:00:20 -0400 (EDT) +Received: from localhost (chriskl@localhost) + by houston.familyhealth.com.au (8.11.6/8.11.6) with ESMTP id g3BG0GJ70765; + Fri, 12 Apr 2002 00:00:16 +0800 (WST) + (envelope-from chriskl@familyhealth.com.au) +Date: Fri, 12 Apr 2002 00:00:16 +0800 (WST) +From: Christopher Kings-Lynne +To: Bruce Momjian +cc: Hiroshi Inoue , Tom Lane , + +Subject: Re: [HACKERS] RFC: Restructuring pg_aggregate +In-Reply-To: <200204110419.g3B4J8v29682@candle.pha.pa.us> +Message-ID: <20020411233659.O69846-100000@houston.familyhealth.com.au> +MIME-Version: 1.0 +Content-Type: TEXT/PLAIN; charset=US-ASCII +Status: OR + +> Actually, what we need to do to reclaim space is to enable table +> recreation without the column, now that we have relfilenode for file +> renaming. It isn't hard to do, but no one has focused on it. I want to +> focus on it, but have not had the time, obviously, and would be very +> excited to assist someone else. +> +> Hiroshi's fine idea of marking certain columns as unused would not have +> reclaimed the missing space, just as my idea of physical/logical column +> distinction would not reclaim the space either. Again, my +> physical/logical idea is more for fixing other problems and +> optimization, not DROP COLUMN. + +Hmmm. Personally, I think that a DROP COLUMN that cannot reclaim space is +kinda useless - you may as well just use a view!!! + +So how would this occur?: + +1. Lock target table for writing (allow reads) +2. Begin a table scan on target table, writing + a new file with a particular filenode +3. Delete the attribute row from pg_attribute +4. Point the table in the catalog to the new filenode +5. Release locks +6. Commit transaction +7. Delete orhpan filenode + +i. Upon postmaster startup, remove any orphaned filenodes + +The real problem here is the fact that there are now missing attnos in +pg_attribute. Either that's handled or we renumber the attnos - which is +also quite hard? + +This, of course, suffers from the double size data problem - but I believe +that it does not matter - we just need to document it. + +Interestingly enough, Oracle support + +ALTER TABLE foo SET UNUSED col; + +Which invalidates the attribute entry, and: + +ALTER TABLE foo DROP col CHECKPOINT 1000; + +Which actually reclaims the space. The optional CHECKPOINT [n] clause +tells Oracle to do a checkpoint every [n] rows. + +"Checkpointing cuts down the amount of undo logs accumulated during the +drop column operation to avoid running out of rollback segment space. +However, if this statement is interrupted after a checkpoint has been +applied, the table remains in an unusable state. While the table is +unusable, the only operations allowed on it are DROP TABLE, TRUNCATE +TABLE, and ALTER TABLE DROP COLUMNS CONTINUE (described below). " + +Chris + + + +From pgsql-hackers-owner+M21180@postgresql.org Thu Apr 11 12:02:54 2002 +Return-path: +Received: from postgresql.org (postgresql.org [64.49.215.8]) + by candle.pha.pa.us (8.11.6/8.10.1) with ESMTP id g3BG2sS03611 + for ; Thu, 11 Apr 2002 12:02:54 -0400 (EDT) +Received: from postgresql.org (postgresql.org [64.49.215.8]) + by postgresql.org (Postfix) with SMTP + id 6446B478F0A; Thu, 11 Apr 2002 12:01:19 -0400 (EDT) +Received: from houston.familyhealth.com.au (i231-006.nv.iinet.net.au [203.59.231.6]) + by postgresql.org (Postfix) with ESMTP id B6271478E4C + for ; Thu, 11 Apr 2002 12:00:24 -0400 (EDT) +Received: from localhost (chriskl@localhost) + by houston.familyhealth.com.au (8.11.6/8.11.6) with ESMTP id g3BG0GJ70765; + Fri, 12 Apr 2002 00:00:16 +0800 (WST) + (envelope-from chriskl@familyhealth.com.au) +Date: Fri, 12 Apr 2002 00:00:16 +0800 (WST) +From: Christopher Kings-Lynne +To: Bruce Momjian +cc: Hiroshi Inoue , Tom Lane , + +Subject: Re: [HACKERS] RFC: Restructuring pg_aggregate +In-Reply-To: <200204110419.g3B4J8v29682@candle.pha.pa.us> +Message-ID: <20020411233659.O69846-100000@houston.familyhealth.com.au> +MIME-Version: 1.0 +Content-Type: TEXT/PLAIN; charset=US-ASCII +Precedence: bulk +Sender: pgsql-hackers-owner@postgresql.org +Status: ORr + +> Actually, what we need to do to reclaim space is to enable table +> recreation without the column, now that we have relfilenode for file +> renaming. It isn't hard to do, but no one has focused on it. I want to +> focus on it, but have not had the time, obviously, and would be very +> excited to assist someone else. +> +> Hiroshi's fine idea of marking certain columns as unused would not have +> reclaimed the missing space, just as my idea of physical/logical column +> distinction would not reclaim the space either. Again, my +> physical/logical idea is more for fixing other problems and +> optimization, not DROP COLUMN. + +Hmmm. Personally, I think that a DROP COLUMN that cannot reclaim space is +kinda useless - you may as well just use a view!!! + +So how would this occur?: + +1. Lock target table for writing (allow reads) +2. Begin a table scan on target table, writing + a new file with a particular filenode +3. Delete the attribute row from pg_attribute +4. Point the table in the catalog to the new filenode +5. Release locks +6. Commit transaction +7. Delete orhpan filenode + +i. Upon postmaster startup, remove any orphaned filenodes + +The real problem here is the fact that there are now missing attnos in +pg_attribute. Either that's handled or we renumber the attnos - which is +also quite hard? + +This, of course, suffers from the double size data problem - but I believe +that it does not matter - we just need to document it. + +Interestingly enough, Oracle support + +ALTER TABLE foo SET UNUSED col; + +Which invalidates the attribute entry, and: + +ALTER TABLE foo DROP col CHECKPOINT 1000; + +Which actually reclaims the space. The optional CHECKPOINT [n] clause +tells Oracle to do a checkpoint every [n] rows. + +"Checkpointing cuts down the amount of undo logs accumulated during the +drop column operation to avoid running out of rollback segment space. +However, if this statement is interrupted after a checkpoint has been +applied, the table remains in an unusable state. While the table is +unusable, the only operations allowed on it are DROP TABLE, TRUNCATE +TABLE, and ALTER TABLE DROP COLUMNS CONTINUE (described below). " + +Chris + + + +---------------------------(end of broadcast)--------------------------- +TIP 2: you can get off all lists at once with the unregister command + (send "unregister YourEmailAddressHere" to majordomo@postgresql.org) + +From tgl@sss.pgh.pa.us Thu Apr 11 12:22:44 2002 +Return-path: +Received: from sss.pgh.pa.us (root@[192.204.191.242]) + by candle.pha.pa.us (8.11.6/8.10.1) with ESMTP id g3BGMhS05541 + for ; Thu, 11 Apr 2002 12:22:43 -0400 (EDT) +Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) + by sss.pgh.pa.us (8.11.4/8.11.4) with ESMTP id g3BGMaF01827; + Thu, 11 Apr 2002 12:22:36 -0400 (EDT) +To: Christopher Kings-Lynne +cc: Bruce Momjian , Hiroshi Inoue , + pgsql-hackers@postgresql.org +Subject: Re: [HACKERS] RFC: Restructuring pg_aggregate +In-Reply-To: <20020411233659.O69846-100000@houston.familyhealth.com.au> +References: <20020411233659.O69846-100000@houston.familyhealth.com.au> +Comments: In-reply-to Christopher Kings-Lynne + message dated "Fri, 12 Apr 2002 00:00:16 +0800" +Date: Thu, 11 Apr 2002 12:22:35 -0400 +Message-ID: <1824.1018542155@sss.pgh.pa.us> +From: Tom Lane +Status: ORr + +Christopher Kings-Lynne writes: +> The real problem here is the fact that there are now missing attnos in +> pg_attribute. Either that's handled or we renumber the attnos - which is +> also quite hard? + +Updating pg_attribute per se is not so hard --- just store new copies of +all the rows for the table. However, propagating the changes into other +places could be quite painful (I'm thinking of column numbers in stored +constraints, rules, etc). + +It seems to me that reducing the column to NULLs already gets you the +majority of the space savings. I don't think there is a case to be made +that getting back that last bit is worth the pain involved, either in +implementation effort or direct runtime costs (do you really want a DROP +COLUMN to force an immediate rewrite of the whole table?) + + regards, tom lane + +From pgsql-hackers-owner+M21186@postgresql.org Thu Apr 11 13:03:13 2002 +Return-path: +Received: from postgresql.org (postgresql.org [64.49.215.8]) + by candle.pha.pa.us (8.11.6/8.10.1) with ESMTP id g3BH3DS08942 + for ; Thu, 11 Apr 2002 13:03:13 -0400 (EDT) +Received: from postgresql.org (postgresql.org [64.49.215.8]) + by postgresql.org (Postfix) with SMTP + id 517ED479415; Thu, 11 Apr 2002 12:29:32 -0400 (EDT) +Received: from sss.pgh.pa.us (unknown [192.204.191.242]) + by postgresql.org (Postfix) with ESMTP id B87BC479327 + for ; Thu, 11 Apr 2002 12:22:51 -0400 (EDT) +Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) + by sss.pgh.pa.us (8.11.4/8.11.4) with ESMTP id g3BGMaF01827; + Thu, 11 Apr 2002 12:22:36 -0400 (EDT) +To: Christopher Kings-Lynne +cc: Bruce Momjian , Hiroshi Inoue , + pgsql-hackers@postgresql.org +Subject: Re: [HACKERS] RFC: Restructuring pg_aggregate +In-Reply-To: <20020411233659.O69846-100000@houston.familyhealth.com.au> +References: <20020411233659.O69846-100000@houston.familyhealth.com.au> +Comments: In-reply-to Christopher Kings-Lynne + message dated "Fri, 12 Apr 2002 00:00:16 +0800" +Date: Thu, 11 Apr 2002 12:22:35 -0400 +Message-ID: <1824.1018542155@sss.pgh.pa.us> +From: Tom Lane +Precedence: bulk +Sender: pgsql-hackers-owner@postgresql.org +Status: OR + +Christopher Kings-Lynne writes: +> The real problem here is the fact that there are now missing attnos in +> pg_attribute. Either that's handled or we renumber the attnos - which is +> also quite hard? + +Updating pg_attribute per se is not so hard --- just store new copies of +all the rows for the table. However, propagating the changes into other +places could be quite painful (I'm thinking of column numbers in stored +constraints, rules, etc). + +It seems to me that reducing the column to NULLs already gets you the +majority of the space savings. I don't think there is a case to be made +that getting back that last bit is worth the pain involved, either in +implementation effort or direct runtime costs (do you really want a DROP +COLUMN to force an immediate rewrite of the whole table?) + + regards, tom lane + +---------------------------(end of broadcast)--------------------------- +TIP 4: Don't 'kill -9' the postmaster + +From pgsql-hackers-owner+M21187@postgresql.org Thu Apr 11 13:25:05 2002 +Return-path: +Received: from postgresql.org (postgresql.org [64.49.215.8]) + by candle.pha.pa.us (8.11.6/8.10.1) with ESMTP id g3BHP4S10960 + for ; Thu, 11 Apr 2002 13:25:05 -0400 (EDT) +Received: from postgresql.org (postgresql.org [64.49.215.8]) + by postgresql.org (Postfix) with SMTP + id 2BC27479442; Thu, 11 Apr 2002 12:30:28 -0400 (EDT) +Received: from candle.pha.pa.us (216-55-132-35.dsl.san-diego.abac.net [216.55.132.35]) + by postgresql.org (Postfix) with ESMTP id 265E5479340 + for ; Thu, 11 Apr 2002 12:23:30 -0400 (EDT) +Received: (from pgman@localhost) + by candle.pha.pa.us (8.11.6/8.10.1) id g3BGNS405576; + Thu, 11 Apr 2002 12:23:28 -0400 (EDT) +From: Bruce Momjian +Message-ID: <200204111623.g3BGNS405576@candle.pha.pa.us> +Subject: Re: [HACKERS] RFC: Restructuring pg_aggregate +In-Reply-To: <20020411233659.O69846-100000@houston.familyhealth.com.au> +To: Christopher Kings-Lynne +Date: Thu, 11 Apr 2002 12:23:28 -0400 (EDT) +cc: Hiroshi Inoue , Tom Lane , + pgsql-hackers@postgresql.org +X-Mailer: ELM [version 2.4ME+ PL97 (25)] +MIME-Version: 1.0 +Content-Transfer-Encoding: 7bit +Content-Type: text/plain; charset=US-ASCII +Precedence: bulk +Sender: pgsql-hackers-owner@postgresql.org +Status: OR + +Christopher Kings-Lynne wrote: +> > Actually, what we need to do to reclaim space is to enable table +> > recreation without the column, now that we have relfilenode for file +> > renaming. It isn't hard to do, but no one has focused on it. I want to +> > focus on it, but have not had the time, obviously, and would be very +> > excited to assist someone else. +> > +> > Hiroshi's fine idea of marking certain columns as unused would not have +> > reclaimed the missing space, just as my idea of physical/logical column +> > distinction would not reclaim the space either. Again, my +> > physical/logical idea is more for fixing other problems and +> > optimization, not DROP COLUMN. +> +> Hmmm. Personally, I think that a DROP COLUMN that cannot reclaim space is +> kinda useless - you may as well just use a view!!! + +Yep, kind of a problem. It is a tradeoff between double diskspace/speed +and removing column from disk. I guess that's why Oracle has both. + +> +> So how would this occur?: +> +> 1. Lock target table for writing (allow reads) +> 2. Begin a table scan on target table, writing +> a new file with a particular filenode +> 3. Delete the attribute row from pg_attribute +> 4. Point the table in the catalog to the new filenode +> 5. Release locks +> 6. Commit transaction +> 7. Delete orhpan filenode + +Yep, something like that. CLUSTER is a good start. DROP COLUMN just +deals with the attno too. You would have to renumber them to fill the +gap. + +> i. Upon postmaster startup, remove any orphaned filenodes + +Actually, we don't have a good solution for finding orphaned filenodes +right now. I do have some code that tries to do this as part of VACUUM +but it was not 100% perfect, so it was rejected. I am willing to open +the discussion to see if a perfect solution can be found. + + +-- + Bruce Momjian | http://candle.pha.pa.us + pgman@candle.pha.pa.us | (610) 853-3000 + + If your life is a hard drive, | 830 Blythe Avenue + + Christ can be your backup. | Drexel Hill, Pennsylvania 19026 + +---------------------------(end of broadcast)--------------------------- +TIP 2: you can get off all lists at once with the unregister command + (send "unregister YourEmailAddressHere" to majordomo@postgresql.org) + +From pgsql-hackers-owner+M21190@postgresql.org Thu Apr 11 13:40:34 2002 +Return-path: +Received: from postgresql.org (postgresql.org [64.49.215.8]) + by candle.pha.pa.us (8.11.6/8.10.1) with ESMTP id g3BHeXS12137 + for ; Thu, 11 Apr 2002 13:40:33 -0400 (EDT) +Received: from postgresql.org (postgresql.org [64.49.215.8]) + by postgresql.org (Postfix) with SMTP + id 2BD6C479604; Thu, 11 Apr 2002 12:35:51 -0400 (EDT) +Received: from candle.pha.pa.us (216-55-132-35.dsl.san-diego.abac.net [216.55.132.35]) + by postgresql.org (Postfix) with ESMTP id 2DF9D47946A + for ; Thu, 11 Apr 2002 12:31:25 -0400 (EDT) +Received: (from pgman@localhost) + by candle.pha.pa.us (8.11.6/8.10.1) id g3BGVM806114; + Thu, 11 Apr 2002 12:31:22 -0400 (EDT) +From: Bruce Momjian +Message-ID: <200204111631.g3BGVM806114@candle.pha.pa.us> +Subject: Re: [HACKERS] RFC: Restructuring pg_aggregate +In-Reply-To: <1824.1018542155@sss.pgh.pa.us> +To: Tom Lane +Date: Thu, 11 Apr 2002 12:31:22 -0400 (EDT) +cc: Christopher Kings-Lynne , + Hiroshi Inoue , pgsql-hackers@postgresql.org +X-Mailer: ELM [version 2.4ME+ PL97 (25)] +MIME-Version: 1.0 +Content-Transfer-Encoding: 7bit +Content-Type: text/plain; charset=US-ASCII +Precedence: bulk +Sender: pgsql-hackers-owner@postgresql.org +Status: OR + +Tom Lane wrote: +> Christopher Kings-Lynne writes: +> > The real problem here is the fact that there are now missing attnos in +> > pg_attribute. Either that's handled or we renumber the attnos - which is +> > also quite hard? +> +> Updating pg_attribute per se is not so hard --- just store new copies of +> all the rows for the table. However, propagating the changes into other +> places could be quite painful (I'm thinking of column numbers in stored +> constraints, rules, etc). +> +> It seems to me that reducing the column to NULLs already gets you the +> majority of the space savings. I don't think there is a case to be made +> that getting back that last bit is worth the pain involved, either in +> implementation effort or direct runtime costs (do you really want a DROP +> COLUMN to force an immediate rewrite of the whole table?) + +That is an excellent point about having to fix all the places that refer +to attno. In fact, we have been moving away from attname references to +attno references for a while, so it only gets worse. Tom is also +correct that setting it to NULL removes the problem of disk space usage +quite easily. + +That only leaves the problem of having gaps in the pg_attribute for that +relation, and as I remember, that was the problem for Hiroshi's DROP +COLUMN change, but at this point, after years of delay with no great +solution on the horizon, we may as well just get this working. + +-- + Bruce Momjian | http://candle.pha.pa.us + pgman@candle.pha.pa.us | (610) 853-3000 + + If your life is a hard drive, | 830 Blythe Avenue + + Christ can be your backup. | Drexel Hill, Pennsylvania 19026 + +---------------------------(end of broadcast)--------------------------- +TIP 3: if posting/reading through Usenet, please send an appropriate +subscribe-nomail command to majordomo@postgresql.org so that your +message can get through to the mailing list cleanly + +From Inoue@tpf.co.jp Thu Apr 11 19:55:08 2002 +Return-path: +Received: from sd.tpf.co.jp (IDENT:qmailr@sd.tpf.co.jp [210.161.239.34]) + by candle.pha.pa.us (8.11.6/8.10.1) with SMTP id g3BNt6S19759 + for ; Thu, 11 Apr 2002 19:55:06 -0400 (EDT) +Received: (qmail 31013 invoked from network); 11 Apr 2002 23:55:06 -0000 +Received: from unknown (HELO viscomail.tpf.co.jp) (100.0.0.108) + by sd2.tpf-fw-c.co.jp with SMTP; 11 Apr 2002 23:55:06 -0000 +Received: from tpf.co.jp (3dgateway1 [126.0.1.60]) + by viscomail.tpf.co.jp (8.8.8+Sun/8.8.8) with ESMTP id IAA22335; + Fri, 12 Apr 2002 08:55:05 +0900 (JST) +Message-ID: <3CB62298.88565A54@tpf.co.jp> +Date: Fri, 12 Apr 2002 08:56:08 +0900 +From: Hiroshi Inoue +X-Mailer: Mozilla 4.73 [ja] (Windows NT 5.0; U) +X-Accept-Language: ja +MIME-Version: 1.0 +To: Christopher Kings-Lynne +cc: Bruce Momjian , Tom Lane , + pgsql-hackers@postgresql.org +Subject: Re: [HACKERS] RFC: Restructuring pg_aggregate +References: <20020411233659.O69846-100000@houston.familyhealth.com.au> +Content-Type: text/plain; charset=iso-2022-jp +Content-Transfer-Encoding: 7bit +Status: OR + +Christopher Kings-Lynne wrote: +> +> Hmmm. Personally, I think that a DROP COLUMN that cannot reclaim space is +> kinda useless - you may as well just use a view!!! +> +> So how would this occur?: +> +> 1. Lock target table for writing (allow reads) +> 2. Begin a table scan on target table, writing +> a new file with a particular filenode +> 3. Delete the attribute row from pg_attribute +> 4. Point the table in the catalog to the new filenode +> 5. Release locks +> 6. Commit transaction +> 7. Delete orhpan filenode +> +> i. Upon postmaster startup, remove any orphaned filenodes +> +> The real problem here is the fact that there are now missing attnos in +> pg_attribute. Either that's handled or we renumber the attnos - which is +> also quite hard? + +The attnos should be renumbered and it's easy. +But the above seems only 20% of the total implementation. +If the attnos are renumbered, all objects which refer to +the numbers must be invalidated or re-compiled ... +For example the parameters of foreign key constraints +triggers are consist of relname and colnames currently. +There has been a proposal that change to use relid or +column numbers instead. Certainly it makes RENAME happy +but DROP COLUMN unhappy. If there's a foreign key a_rel/1/3 +and the second column of the relation is dropped the +parameter must be changed to be a_rel/1/2. If neither +foreign key stuff nor DROP COLUMN take the other into +account, the consistency is easily broken. + +regards, +Hiroshi Inoue + +From pgsql-hackers-owner+M21205@postgresql.org Thu Apr 11 19:56:20 2002 +Return-path: +Received: from postgresql.org (postgresql.org [64.49.215.8]) + by candle.pha.pa.us (8.11.6/8.10.1) with ESMTP id g3BNuJS19855 + for ; Thu, 11 Apr 2002 19:56:19 -0400 (EDT) +Received: from postgresql.org (postgresql.org [64.49.215.8]) + by postgresql.org (Postfix) with SMTP + id 2B38A47656E; Thu, 11 Apr 2002 19:55:57 -0400 (EDT) +Received: from sd.tpf.co.jp (sd.tpf.co.jp [210.161.239.34]) + by postgresql.org (Postfix) with SMTP id 6C92E475C96 + for ; Thu, 11 Apr 2002 19:55:04 -0400 (EDT) +Received: (qmail 31013 invoked from network); 11 Apr 2002 23:55:06 -0000 +Received: from unknown (HELO viscomail.tpf.co.jp) (100.0.0.108) + by sd2.tpf-fw-c.co.jp with SMTP; 11 Apr 2002 23:55:06 -0000 +Received: from tpf.co.jp (3dgateway1 [126.0.1.60]) + by viscomail.tpf.co.jp (8.8.8+Sun/8.8.8) with ESMTP id IAA22335; + Fri, 12 Apr 2002 08:55:05 +0900 (JST) +Message-ID: <3CB62298.88565A54@tpf.co.jp> +Date: Fri, 12 Apr 2002 08:56:08 +0900 +From: Hiroshi Inoue +X-Mailer: Mozilla 4.73 [ja] (Windows NT 5.0; U) +X-Accept-Language: ja +MIME-Version: 1.0 +To: Christopher Kings-Lynne +cc: Bruce Momjian , Tom Lane , + pgsql-hackers@postgresql.org +Subject: Re: [HACKERS] RFC: Restructuring pg_aggregate +References: <20020411233659.O69846-100000@houston.familyhealth.com.au> +Content-Type: text/plain; charset=iso-2022-jp +Content-Transfer-Encoding: 7bit +Precedence: bulk +Sender: pgsql-hackers-owner@postgresql.org +Status: ORr + +Christopher Kings-Lynne wrote: +> +> Hmmm. Personally, I think that a DROP COLUMN that cannot reclaim space is +> kinda useless - you may as well just use a view!!! +> +> So how would this occur?: +> +> 1. Lock target table for writing (allow reads) +> 2. Begin a table scan on target table, writing +> a new file with a particular filenode +> 3. Delete the attribute row from pg_attribute +> 4. Point the table in the catalog to the new filenode +> 5. Release locks +> 6. Commit transaction +> 7. Delete orhpan filenode +> +> i. Upon postmaster startup, remove any orphaned filenodes +> +> The real problem here is the fact that there are now missing attnos in +> pg_attribute. Either that's handled or we renumber the attnos - which is +> also quite hard? + +The attnos should be renumbered and it's easy. +But the above seems only 20% of the total implementation. +If the attnos are renumbered, all objects which refer to +the numbers must be invalidated or re-compiled ... +For example the parameters of foreign key constraints +triggers are consist of relname and colnames currently. +There has been a proposal that change to use relid or +column numbers instead. Certainly it makes RENAME happy +but DROP COLUMN unhappy. If there's a foreign key a_rel/1/3 +and the second column of the relation is dropped the +parameter must be changed to be a_rel/1/2. If neither +foreign key stuff nor DROP COLUMN take the other into +account, the consistency is easily broken. + +regards, +Hiroshi Inoue + +---------------------------(end of broadcast)--------------------------- +TIP 6: Have you searched our list archives? + +http://archives.postgresql.org + +From pgsql-hackers-owner+M21209@postgresql.org Thu Apr 11 22:27:40 2002 +Return-path: +Received: from postgresql.org (postgresql.org [64.49.215.8]) + by candle.pha.pa.us (8.11.6/8.10.1) with ESMTP id g3C2ReS27660 + for ; Thu, 11 Apr 2002 22:27:40 -0400 (EDT) +Received: from postgresql.org (postgresql.org [64.49.215.8]) + by postgresql.org (Postfix) with SMTP + id A89AF4766D0; Thu, 11 Apr 2002 22:27:35 -0400 (EDT) +Received: from candle.pha.pa.us (216-55-132-35.dsl.san-diego.abac.net [216.55.132.35]) + by postgresql.org (Postfix) with ESMTP id 4CE13475EB9 + for ; Thu, 11 Apr 2002 22:26:25 -0400 (EDT) +Received: (from pgman@localhost) + by candle.pha.pa.us (8.11.6/8.10.1) id g3C2Q5I27551; + Thu, 11 Apr 2002 22:26:05 -0400 (EDT) +From: Bruce Momjian +Message-ID: <200204120226.g3C2Q5I27551@candle.pha.pa.us> +Subject: Re: [HACKERS] RFC: Restructuring pg_aggregate +In-Reply-To: <3CB62298.88565A54@tpf.co.jp> +To: Hiroshi Inoue +Date: Thu, 11 Apr 2002 22:26:05 -0400 (EDT) +cc: Christopher Kings-Lynne , + Tom Lane , pgsql-hackers@postgresql.org +X-Mailer: ELM [version 2.4ME+ PL97 (25)] +MIME-Version: 1.0 +Content-Transfer-Encoding: 7bit +Content-Type: text/plain; charset=US-ASCII +Precedence: bulk +Sender: pgsql-hackers-owner@postgresql.org +Status: OR + +Hiroshi Inoue wrote: +> Christopher Kings-Lynne wrote: +> > +> > Hmmm. Personally, I think that a DROP COLUMN that cannot reclaim space is +> > kinda useless - you may as well just use a view!!! +> > +> > So how would this occur?: +> > +> > 1. Lock target table for writing (allow reads) +> > 2. Begin a table scan on target table, writing +> > a new file with a particular filenode +> > 3. Delete the attribute row from pg_attribute +> > 4. Point the table in the catalog to the new filenode +> > 5. Release locks +> > 6. Commit transaction +> > 7. Delete orhpan filenode +> > +> > i. Upon postmaster startup, remove any orphaned filenodes +> > +> > The real problem here is the fact that there are now missing attnos in +> > pg_attribute. Either that's handled or we renumber the attnos - which is +> > also quite hard? +> +> The attnos should be renumbered and it's easy. +> But the above seems only 20% of the total implementation. +> If the attnos are renumbered, all objects which refer to +> the numbers must be invalidated or re-compiled ... +> For example the parameters of foreign key constraints +> triggers are consist of relname and colnames currently. +> There has been a proposal that change to use relid or +> column numbers instead. Certainly it makes RENAME happy +> but DROP COLUMN unhappy. If there's a foreign key a_rel/1/3 +> and the second column of the relation is dropped the +> parameter must be changed to be a_rel/1/2. If neither +> foreign key stuff nor DROP COLUMN take the other into +> account, the consistency is easily broken. + +I think that is why Tom was suggesting making all the column values NULL +and removing the pg_attribute row for the column. With a NULL value, it +doesn't take up any room in the tuple, and with the pg_attribute column +gone, no one will see that row. The only problem is the gap in attno +numbering. How big a problem is that? + +-- + Bruce Momjian | http://candle.pha.pa.us + pgman@candle.pha.pa.us | (610) 853-3000 + + If your life is a hard drive, | 830 Blythe Avenue + + Christ can be your backup. | Drexel Hill, Pennsylvania 19026 + +---------------------------(end of broadcast)--------------------------- +TIP 2: you can get off all lists at once with the unregister command + (send "unregister YourEmailAddressHere" to majordomo@postgresql.org) + +From pgsql-hackers-owner+M21211@postgresql.org Thu Apr 11 22:55:44 2002 +Return-path: +Received: from postgresql.org (postgresql.org [64.49.215.8]) + by candle.pha.pa.us (8.11.6/8.10.1) with ESMTP id g3C2tiS29394 + for ; Thu, 11 Apr 2002 22:55:44 -0400 (EDT) +Received: from postgresql.org (postgresql.org [64.49.215.8]) + by postgresql.org (Postfix) with SMTP + id B86AF476739; Thu, 11 Apr 2002 22:55:39 -0400 (EDT) +Received: from sss.pgh.pa.us (unknown [192.204.191.242]) + by postgresql.org (Postfix) with ESMTP id 56D8747593C + for ; Thu, 11 Apr 2002 22:54:26 -0400 (EDT) +Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) + by sss.pgh.pa.us (8.11.4/8.11.4) with ESMTP id g3C2s1F24007; + Thu, 11 Apr 2002 22:54:01 -0400 (EDT) +To: Bruce Momjian +cc: Hiroshi Inoue , + Christopher Kings-Lynne , + pgsql-hackers@postgresql.org +Subject: Re: [HACKERS] RFC: Restructuring pg_aggregate +In-Reply-To: <200204120226.g3C2Q5I27551@candle.pha.pa.us> +References: <200204120226.g3C2Q5I27551@candle.pha.pa.us> +Comments: In-reply-to Bruce Momjian + message dated "Thu, 11 Apr 2002 22:26:05 -0400" +Date: Thu, 11 Apr 2002 22:54:01 -0400 +Message-ID: <24004.1018580041@sss.pgh.pa.us> +From: Tom Lane +Precedence: bulk +Sender: pgsql-hackers-owner@postgresql.org +Status: OR + +Bruce Momjian writes: +> I think that is why Tom was suggesting making all the column values NULL +> and removing the pg_attribute row for the column. + +That was not my suggestion. + +> With a NULL value, it +> doesn't take up any room in the tuple, and with the pg_attribute column +> gone, no one will see that row. The only problem is the gap in attno +> numbering. How big a problem is that? + +You can't do it that way unless you're intending to rewrite all rows of +the relation before committing the ALTER; which would be the worst of +both worlds. The pg_attribute row *must* be retained to show the +datatype of the former column, so that we can correctly skip over it +in tuples where the column isn't yet nulled out. + +Hiroshi did this by renumbering the attnum; I propose leaving attnum +alone and instead adding an attisdropped flag. That would avoid +creating a gap in the column numbers, but either way is likely to affect +some applications that inspect pg_attribute. + + regards, tom lane + +---------------------------(end of broadcast)--------------------------- +TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org + +From pgsql-hackers-owner+M21214@postgresql.org Fri Apr 12 00:09:26 2002 +Return-path: +Received: from postgresql.org (postgresql.org [64.49.215.8]) + by candle.pha.pa.us (8.11.6/8.10.1) with ESMTP id g3C49PS05093 + for ; Fri, 12 Apr 2002 00:09:25 -0400 (EDT) +Received: from postgresql.org (postgresql.org [64.49.215.8]) + by postgresql.org (Postfix) with SMTP + id B1BE6476810; Fri, 12 Apr 2002 00:09:20 -0400 (EDT) +Received: from sd.tpf.co.jp (sd.tpf.co.jp [210.161.239.34]) + by postgresql.org (Postfix) with SMTP id A8E07476444 + for ; Fri, 12 Apr 2002 00:08:22 -0400 (EDT) +Received: (qmail 25808 invoked from network); 12 Apr 2002 04:08:26 -0000 +Received: from unknown (HELO viscomail.tpf.co.jp) (100.0.0.108) + by sd2.tpf-fw-c.co.jp with SMTP; 12 Apr 2002 04:08:26 -0000 +Received: from tpf.co.jp (3dgateway1 [126.0.1.60]) + by viscomail.tpf.co.jp (8.8.8+Sun/8.8.8) with ESMTP id NAA22497; + Fri, 12 Apr 2002 13:08:24 +0900 (JST) +Message-ID: <3CB65DF7.8FCFC024@tpf.co.jp> +Date: Fri, 12 Apr 2002 13:09:28 +0900 +From: Hiroshi Inoue +X-Mailer: Mozilla 4.73 [ja] (Windows NT 5.0; U) +X-Accept-Language: ja +MIME-Version: 1.0 +To: Bruce Momjian +cc: Christopher Kings-Lynne , + Tom Lane , pgsql-hackers@postgresql.org +Subject: Re: [HACKERS] RFC: Restructuring pg_aggregate +References: <200204120226.g3C2Q5I27551@candle.pha.pa.us> +Content-Type: text/plain; charset=iso-2022-jp +Content-Transfer-Encoding: 7bit +Precedence: bulk +Sender: pgsql-hackers-owner@postgresql.org +Status: OR + +Bruce Momjian wrote: +> +> Hiroshi Inoue wrote: +> > Christopher Kings-Lynne wrote: +> > > +> I think that is why Tom was suggesting making all the column values NULL +> and removing the pg_attribute row for the column. With a NULL value, it +> doesn't take up any room in the tuple, and with the pg_attribute column +> gone, no one will see that row. The only problem is the gap in attno +> numbering. How big a problem is that? + +There's no problem with applications which don't inquire +of system catalogs(pg_attribute). Unfortunately we have +been very tolerant of users' access on system tables and +there would be pretty many applications which inquire of +pg_attribute. + +regards, +Hiroshi Inoue + +---------------------------(end of broadcast)--------------------------- +TIP 5: Have you checked our extensive FAQ? + +http://www.postgresql.org/users-lounge/docs/faq.html + +From pgsql-hackers-owner+M21221@postgresql.org Fri Apr 12 05:11:00 2002 +Return-path: +Received: from postgresql.org (postgresql.org [64.49.215.8]) + by candle.pha.pa.us (8.11.6/8.10.1) with ESMTP id g3C9AxS28516 + for ; Fri, 12 Apr 2002 05:11:00 -0400 (EDT) +Received: from postgresql.org (postgresql.org [64.49.215.8]) + by postgresql.org (Postfix) with SMTP + id 28FF0476B9D; Fri, 12 Apr 2002 04:35:54 -0400 (EDT) +Received: from tele-post-20.mail.demon.net (tele-post-20.mail.demon.net [194.217.242.20]) + by postgresql.org (Postfix) with ESMTP id BFDE74769AC + for ; Fri, 12 Apr 2002 04:30:29 -0400 (EDT) +Received: from mailgate.vale-housing.co.uk ([193.195.77.162] helo=dogbert.vale-housing.co.uk) + by tele-post-20.mail.demon.net with esmtp (Exim 3.35 #1) + id 16vwRc-0006GP-0K; Fri, 12 Apr 2002 08:30:08 +0000 +Received: by dogbert.vale-housing.co.uk with Internet Mail Service (5.5.2650.21) + id <2H2ZS6HB>; Fri, 12 Apr 2002 09:35:53 +0100 +Message-ID: +From: Dave Page +To: "'Tom Lane'" , Bruce Momjian +cc: Hiroshi Inoue , + Christopher Kings-Lynne , + pgsql-hackers@postgresql.org +Subject: Re: [HACKERS] RFC: Restructuring pg_aggregate +Date: Fri, 12 Apr 2002 09:35:52 +0100 +MIME-Version: 1.0 +X-Mailer: Internet Mail Service (5.5.2650.21) +Content-Type: text/plain +Precedence: bulk +Sender: pgsql-hackers-owner@postgresql.org +Status: OR + + + +> -----Original Message----- +> From: Tom Lane [mailto:tgl@sss.pgh.pa.us] +> Sent: 12 April 2002 03:54 +> To: Bruce Momjian +> Cc: Hiroshi Inoue; Christopher Kings-Lynne; +> pgsql-hackers@postgresql.org +> Subject: Re: RFC: Restructuring pg_aggregate +> +> +> Bruce Momjian writes: +> > I think that is why Tom was suggesting making all the column values +> > NULL and removing the pg_attribute row for the column. +> +> That was not my suggestion. +> +> > With a NULL value, it +> > doesn't take up any room in the tuple, and with the pg_attribute +> > column gone, no one will see that row. The only problem is +> the gap in +> > attno numbering. How big a problem is that? +> +> You can't do it that way unless you're intending to rewrite +> all rows of the relation before committing the ALTER; which +> would be the worst of both worlds. The pg_attribute row +> *must* be retained to show the datatype of the former column, +> so that we can correctly skip over it in tuples where the +> column isn't yet nulled out. +> +> Hiroshi did this by renumbering the attnum; I propose leaving +> attnum alone and instead adding an attisdropped flag. That +> would avoid creating a gap in the column numbers, but either +> way is likely to affect some applications that inspect pg_attribute. + +Applications like pgAdmin that inspect pg_attribute are being seriously +hacked to incorporate schema support anyway for 7.3. Personnally I'd be glad +to spend some time re-coding to allow for this, just to not have to answer +the numerous 'how do I drop a column' emails I get reguarly. + +Regards, Dave. + +---------------------------(end of broadcast)--------------------------- +TIP 2: you can get off all lists at once with the unregister command + (send "unregister YourEmailAddressHere" to majordomo@postgresql.org) + +From chriskl@familyhealth.com.au Sat Apr 13 02:25:23 2002 +Return-path: +Received: from mail.iinet.net.au (symphony-01.iinet.net.au [203.59.3.33]) + by candle.pha.pa.us (8.11.6/8.10.1) with SMTP id g3D6PLS06807 + for ; Sat, 13 Apr 2002 02:25:22 -0400 (EDT) +Received: (qmail 7569 invoked by uid 666); 13 Apr 2002 06:25:20 -0000 +Received: from unknown (HELO SOL) (203.59.103.193) + by mail.iinet.net.au with SMTP; 13 Apr 2002 06:25:20 -0000 +Message-ID: <001701c1e2b2$e7b10a40$0200a8c0@SOL> +From: "Christopher Kings-Lynne" +To: "Tom Lane" +cc: "Bruce Momjian" , + "Hiroshi Inoue" , +References: <20020411233659.O69846-100000@houston.familyhealth.com.au> <1824.1018542155@sss.pgh.pa.us> +Subject: Re: [HACKERS] RFC: Restructuring pg_aggregate +Date: Sat, 13 Apr 2002 14:17:34 +0800 +MIME-Version: 1.0 +Content-Type: text/plain; + charset="iso-8859-1" +Content-Transfer-Encoding: 7bit +X-Priority: 3 +X-MSMail-Priority: Normal +X-Mailer: Microsoft Outlook Express 5.50.4522.1200 +X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 +Status: OR + +> Updating pg_attribute per se is not so hard --- just store new copies of +> all the rows for the table. However, propagating the changes into other +> places could be quite painful (I'm thinking of column numbers in stored +> constraints, rules, etc). +> +> It seems to me that reducing the column to NULLs already gets you the +> majority of the space savings. I don't think there is a case to be made +> that getting back that last bit is worth the pain involved, either in +> implementation effort or direct runtime costs (do you really want a DROP +> COLUMN to force an immediate rewrite of the whole table?) + +OK, sounds fair. However, is there a more aggressive way of reclaiming the +space? The problem with updating all the rows to null for that column is +that the on-disk size is doubled anyway, right? So, could a VACUUM FULL +process do the nulling for us? Vacuum works outside of normal transaction +constraints anyway...? + +Also, it seems to me that at some point we are forced to break client +compatibility. Either we add attisdropped field to pg_attribute, or we use +Hiroshi's (-1 * attnum - offset) idea. Both Tom and Hiroshi have good +reasons for each of these - would it be possible for you guys to post with +your reasons for and against both the techniques. I just want to get to an +implementation specification we all agree on that can be written up and then +the coding can proceed. Maybe we should add it to the 'Postgres Major +Projects' page - and remove those old ones that have already been +implemented. + +Chris + + + +From Inoue@tpf.co.jp Sun Apr 14 23:47:08 2002 +Return-path: +Received: from sd.tpf.co.jp (IDENT:qmailr@sd.tpf.co.jp [210.161.239.34]) + by candle.pha.pa.us (8.11.6/8.10.1) with SMTP id g3F3l6S23155 + for ; Sun, 14 Apr 2002 23:47:07 -0400 (EDT) +Received: (qmail 9638 invoked from network); 15 Apr 2002 03:47:06 -0000 +Received: from unknown (HELO viscomail.tpf.co.jp) (100.0.0.108) + by sd2.tpf-fw-c.co.jp with SMTP; 15 Apr 2002 03:47:06 -0000 +Received: from tpf.co.jp (3dgateway1 [126.0.1.60]) + by viscomail.tpf.co.jp (8.8.8+Sun/8.8.8) with ESMTP id MAA24068; + Mon, 15 Apr 2002 12:47:04 +0900 (JST) +Message-ID: <3CBA4D7A.9E61DECA@tpf.co.jp> +Date: Mon, 15 Apr 2002 12:48:10 +0900 +From: Hiroshi Inoue +X-Mailer: Mozilla 4.73 [ja] (Windows NT 5.0; U) +X-Accept-Language: ja +MIME-Version: 1.0 +To: Christopher Kings-Lynne +cc: Tom Lane , Bruce Momjian , + pgsql-hackers@postgresql.org +Subject: Re: [HACKERS] RFC: Restructuring pg_aggregate +References: <20020411233659.O69846-100000@houston.familyhealth.com.au> <1824.1018542155@sss.pgh.pa.us> <001701c1e2b2$e7b10a40$0200a8c0@SOL> +Content-Type: text/plain; charset=iso-2022-jp +Content-Transfer-Encoding: 7bit +Status: OR + +Christopher Kings-Lynne wrote: +> +> Also, it seems to me that at some point we are forced to break client +> compatibility. + +It's not a users' consensus at all. I'm suspicious if +DROP COLUMN is such a significant feature to break +client compatibility at our ease. + +> Either we add attisdropped field to pg_attribute, or we use +> Hiroshi's (-1 * attnum - offset) idea. Both Tom and Hiroshi have good +> reasons for each of these - would it be possible for you guys to post with +> your reasons for and against both the techniques. + +I don't object to adding attisdropped field. What +I meant to say is that the differene is very small. + +regards, +Hiroshi Inoue +