Received: from localhost (unknown [200.46.204.183]) by postgresql.org (Postfix) with ESMTP id 732472E0110 for ; Mon, 17 Dec 2007 03:35:44 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 07886-09 for ; Mon, 17 Dec 2007 03:35:41 -0400 (AST) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.180]) by postgresql.org (Postfix) with ESMTP id B10872E011A for ; Mon, 17 Dec 2007 03:35:39 -0400 (AST) Received: by wa-out-1112.google.com with SMTP id m38so3385636waf.5 for ; Sun, 16 Dec 2007 23:35:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=9kBqWmN8bF8ila4cu6m02TRGKNA/0z8R9JyZG4v/XBk=; b=elYA1to0xPk1LiOFaE8m1ZMPsVnwisea8by0RsKzG74oOW9PoDPsA/fK81CCTrW+HpI+lNh/TTtimbGZvykRAi2heyrwg9iNvgyRwuCswE03z2fSdY22oVp8p1p8ebyakbtdTbJxN7rFPKUuY2nLycIy87+H1KUZcenqI7xvFPo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=MHkDSahLLnOjr9ImhgGtEcu41XI+0Tuekd52Dv4jf5jvic5o5FQqEKefLp4ieMcDbr8/Bg+YXKN7xBWvLwSCEJB+nEfTPdYnkOSI/foRmbWJjyofOA6zYmuJYhp4luQbh4kJyVj/o3b81/S6l8rIR7lx8jj3Q98zEG5kcPFDx/s= Received: by 10.114.175.16 with SMTP id x16mr2168073wae.12.1197876935192; Sun, 16 Dec 2007 23:35:35 -0800 (PST) Received: by 10.114.169.8 with HTTP; Sun, 16 Dec 2007 23:35:35 -0800 (PST) Message-ID: Date: Mon, 17 Dec 2007 13:05:35 +0530 From: NikhilS To: "Tom Lane" Subject: Re: VLDB Features Cc: "Neil Conway" , "Hannu Krosing" , "Josh Berkus" , pgsql-hackers@postgresql.org, "Simon Riggs" In-Reply-To: <7907.1197704696@sss.pgh.pa.us> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_5806_33224838.1197876935186" References: <1197371508.4255.1327.camel@ebony.site> <200712111053.11178.josh@agliodbs.com> <1197416461.29432.10.camel@dell.linuxdev.us.dell.com> <1197636530.7974.16.camel@hannu-laptop> <1197660423.1536.8.camel@dell.linuxdev.us.dell.com> <15007.1197674561@sss.pgh.pa.us> <1197677930.1536.18.camel@dell.linuxdev.us.dell.com> <7907.1197704696@sss.pgh.pa.us> X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200712/624 X-Sequence-Number: 111913 ------=_Part_5806_33224838.1197876935186 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, On Dec 15, 2007 1:14 PM, Tom Lane wrote: > NikhilS writes: > > Any errors which occur before doing the heap_insert should not require > > any recovery according to me. > > A sufficient (though far from all-encompassing) rejoinder to that is > "triggers and CHECK constraints can do anything". > > > The overhead of having a subtransaction per row is a very valid concern. > But > > instead of using a per insert or a batch insert substraction, I am > > thinking that we can start off a subtraction and continue it till we > > encounter a failure.The moment an error is encountered, since we have > the offending >(already in heap) tuple around, we can call a > simple_heap_delete on the same and commit >(instead of aborting) this > subtransaction > > What of failures that occur only at (sub)transaction commit, such as > foreign key checks? > What if we identify and define a subset where we could do subtransactions based COPY? The following could be supported: * A subset of triggers and CHECK constraints which do not move the tuple around. (Identifying this subset might be an issue though?) * Primary/unique key indexes As Hannu mentioned elsewhere in this thread, there should not be very many instances of complex triggers/CHECKs around? And may be in those instances (and also the foreign key checks case), the behaviour could default to use a per-subtransaction-per-row or even the existing single transaction model? Regards, Nikhils -- EnterpriseDB http://www.enterprisedb.com ------=_Part_5806_33224838.1197876935186 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi,

On Dec 15, 2007 1:14 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
NikhilS <nikkhils@gmail.com> writes:
> Any errors which occur before doing the heap_insert should not require
> any recovery according to me.

A sufficient (though far from all-encompassing) rejoinder to that is
"triggers and CHECK constraints can do anything".

> The overhead of having a subtransaction per row is a very valid concern. But
> instead of using a per insert or a batch insert substraction, I am
> thinking that we can start off a subtraction and continue it till we
> encounter a failure.The moment an error is encountered, since we have the offending >(already in heap) tuple around, we can call a simple_heap_delete on the same and commit >(instead of aborting) this subtransaction

What of failures that occur only at (sub)transaction commit, such as
foreign key checks?

What if we identify and define a subset where we could do subtransactions based COPY? The following could be supported:

* A subset of triggers and CHECK constraints which do not move the tuple around. (Identifying this subset might be an issue though?)
* Primary/unique key indexes

As Hannu mentioned elsewhere in this thread, there should not be very many instances of complex triggers/CHECKs around? And  may be in those instances (and also the foreign key checks case), the behaviour could default to use a per-subtransaction-per-row or even the existing single transaction model?

Regards,
Nikhils
--
EnterpriseDB               http://www.enterprisedb.com ------=_Part_5806_33224838.1197876935186--