Received: from magus.postgresql.org (magus.postgresql.org [87.238.57.229])
	by mail.postgresql.org (Postfix) with ESMTP id BA18D1F6FE32
	for <pgsql-performance@postgresql.org>;
	Wed, 11 Jul 2012 18:32:52 -0300 (ADT)
Received: from mail-ee0-f46.google.com ([74.125.83.46])
	by magus.postgresql.org with esmtp (Exim 4.72)
	(envelope-from <mthornton@optrak.com>) id 1Sp4Wf-00064y-Lk
	for pgsql-performance@postgresql.org; Wed, 11 Jul 2012 21:32:51 +0000
Received: by eekb15 with SMTP id b15so411234eek.19
	for <pgsql-performance@postgresql.org>;
	Wed, 11 Jul 2012 14:32:36 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=message-id:date:from:user-agent:mime-version:to:subject:references
	:in-reply-to:content-type:content-transfer-encoding
	:x-gm-message-state;
	bh=3ifFN6p5asBNjthg9DIQFgiNWYI6by4dkb2NarOOm9I=;
	b=c9QMYS6ckdyRKabIc+NFVdWvX152GskR5P/ktUmeSZPKa8zMTp2VfzXIxtJxvtOKzF
	O7uEIHbiAlwTp6JtBb5m7YnzWWVxJY5pZzEbjGhWnQrh8KYgIlNWF2iVup59MJ3Ol0Ra
	zQFRbxGrG7PVGUpgFtCQzIQEFkgPOWui6hyuRG4jB9T6dkDvLbZfQ8u0FILoB29l6zfJ
	xLOEfSldbRKs7r9yKfvUzpuFxaSobSjcF2BP1Ke6WQj4KN7BnCxkwEHlvO/deUnl7tzD
	SJo2ejkzE0gFoVF4u5RP8E8WJN9V+EVMSTYdlHcm2F7iVU2AFqm4Et2bHOzSQD/tYyBw
	g61A==
Received: by 10.14.27.204 with SMTP id e52mr705071eea.53.1342042356022;
	Wed, 11 Jul 2012 14:32:36 -0700 (PDT)
Received: from [192.168.0.110]
	(cpc4-ware5-2-0-cust97.9-1.cable.virginmedia.com. [86.5.172.98])
	by mx.google.com with ESMTPS id a4sm9369934een.14.2012.07.11.14.32.34
	(version=SSLv3 cipher=OTHER); Wed, 11 Jul 2012 14:32:35 -0700 (PDT)
Message-ID: <4FFDF0F1.9010005@optrak.com>
Date: Wed, 11 Jul 2012 22:32:33 +0100
From: Mark Thornton <mthornton@optrak.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:13.0) Gecko/20120615 Thunderbird/13.0.1
MIME-Version: 1.0
To: pgsql-performance@postgresql.org, cjames@emolecules.com
Subject: Re: DELETE vs TRUNCATE explanation
References: <4FFCCAC4.4030503@ringerc.id.au>
	<CAAZKuFZ9tYeC1K5ZayZgztm3re_7ytbsEYFa0wwXirB6Hfm+EQ@mail.gmail.com>
	<23853.1342015548@sss.pgh.pa.us>
	<CAFwQ8rcR5mimJO5FumcYzkgoxkNiP3g3XOaHB1H4oHe-QnLRPQ@mail.gmail.com>
In-Reply-To: 
 <CAFwQ8rcR5mimJO5FumcYzkgoxkNiP3g3XOaHB1H4oHe-QnLRPQ@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Gm-Message-State: 
 ALoCoQmJBxBW6wKlV5GaiC3zmvfd3A5he52018CkZe/SVCwwt37zwx4xNfcqMg092L8Iy2G0lQuz
X-Pg-Spam-Score: -2.6 (--)
X-Archive-Number: 201207/140
X-Sequence-Number: 47321

On 11/07/12 21:18, Craig James wrote:
>
> It strikes me as a contrived case rather than a use case.  What sort 
> of app repeatedly fills and truncates a small table thousands of times 
> ... other than a test app to see whether you can do it or not?
If I have a lot of data which updates/inserts an existing table but I 
don't know if a given record will be an update or an insert, then I 
write all the 'new' data to a temporary table and then use sql 
statements to achieve the updates and inserts on the existing table.

Is there a better way of doing this in standard SQL?

Mark