Received: from localhost (unknown [200.46.204.182]) by postgresql.org (Postfix) with ESMTP id 18A5C2E01EB for ; Sun, 16 Dec 2007 06:13:29 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.182]) (amavisd-maia, port 10024) with ESMTP id 09855-04 for ; Sun, 16 Dec 2007 06:13:18 -0400 (AST) Received: from mail.skype.net (mail.skype.net [193.88.6.4]) by postgresql.org (Postfix) with ESMTP id CD2962E0381 for ; Sun, 16 Dec 2007 06:13:21 -0400 (AST) Received: from mail.skype.net (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id F22DC1100B4; Sun, 16 Dec 2007 11:13:18 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=skype.net; h=subject:from:to:cc:in-reply-to:references:content-type:date:message-id:mime-version:content-transfer-encoding; q=dns/txt; s=mail; bh=fa35+rkIvNzYAFHMasXpUtCviJs=; b=bVoDQZwLbnb8Kbzml2atLTiDLZCdx1Qzz+R69RdTsLyAQCVzGDmevzXITypQKQVibyFpVWe97GDDYqiAcv9krsc4QD3is8v81v57jR8yiW7xwrfoNm0TadEhK7rb/GkBw0sQbayfk+gwnPqrMTZ49nJrZpzTH5zmo+ztIjpBjj8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=skype.net; h=subject:from:to:cc:in-reply-to:references:content-type:date:message-id:mime-version:content-transfer-encoding; q=dns; s=mail; b=Ne17u0D99C9SBDzbm5wCx4ISO+aNCOvct5JLbz2J8DRrnU0iAsikowXDLS4iWj42/BU6p5jbDcBDbwrc4WwvKYvdYVgu6rk/cnwoH85FPPMVMNwvtuqMcOVVxvcaMh0w8luBS0O/Q7DyRFhlmOIjBl1Xk65C+lMa16vLbcoR70A= Received: from localhost (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id E3E841100A8; Sun, 16 Dec 2007 11:13:18 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at skype.net Received: from mail.skype.net ([127.0.0.1]) by localhost (mail.skype.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B4n1EP3APIZP; Sun, 16 Dec 2007 11:13:14 +0100 (CET) Received: from [192.168.2.102] (unknown [81.25.252.5]) by mail.skype.net (Postfix) with ESMTP id EA6251100A5; Sun, 16 Dec 2007 11:13:13 +0100 (CET) Subject: Re: VLDB Features From: Hannu Krosing To: Tom Lane Cc: Josh Berkus , Neil Conway , pgsql-hackers@postgresql.org, Simon Riggs In-Reply-To: <6430.1197699178@sss.pgh.pa.us> References: <1197371508.4255.1327.camel@ebony.site> <1197677930.1536.18.camel@dell.linuxdev.us.dell.com> <16876.1197680636@sss.pgh.pa.us> <200712142034.57808.josh@agliodbs.com> <6430.1197699178@sss.pgh.pa.us> Content-Type: text/plain; charset=utf-8 Date: Sat, 15 Dec 2007 13:10:30 +0200 Message-Id: <1197717031.7974.23.camel@hannu-laptop> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200712/609 X-Sequence-Number: 111898 =C3=9Chel kenal p=C3=A4eval, L, 2007-12-15 kell 01:12, kirjutas Tom Lane: > Josh Berkus writes: > > There's no way we can do a transactionless load, then? I'm thinking = of the=20 > > load-into-new-partition which is a single pass/fail operation. Would= =20 > > ignoring individual row errors in for this case still cause these kin= ds of=20 > > problems? >=20 > Given that COPY fires triggers and runs CHECK constraints, there is no > part of the system that cannot be exercised during COPY. So I think > supposing that we can just deal with some simplified subset of reality > is mere folly. But can't we _define_ such a subset, where we can do a transactionless load ? I don't think that most DW/VLDB schemas fire complex triggers or custom data-modifying functions inside CHECK's. Then we could just run the remaining simple CHECK constraints ourselves and not abort on non-check, but just log the rows ? The COPY ... WITH ERRORS TO ... would essentially become a big conditional RULE through which the incoming data is processed. ------------------ Hannu