X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org
Received: from localhost (unknown [200.46.204.144])
	by svr1.postgresql.org (Postfix) with ESMTP id 3DCBE529D4
	for <pgsql-performance-postgresql.org@localhost.postgresql.org>;
	Mon, 28 Mar 2005 11:22:47 +0100 (BST)
Received: from svr1.postgresql.org ([200.46.204.71])
	by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024)
	with ESMTP id 98494-08
	for <pgsql-performance-postgresql.org@localhost.postgresql.org>;
	Mon, 28 Mar 2005 10:22:38 +0000 (GMT)
Received: from cmailm1.svr.pol.co.uk (cmailm1.svr.pol.co.uk [195.92.193.18])
	by svr1.postgresql.org (Postfix) with ESMTP id 3266353B77
	for <pgsql-performance@postgresql.org>;
	Mon, 28 Mar 2005 11:22:37 +0100 (BST)
Received: from modem-4021.llama.dialup.pol.co.uk ([217.135.191.181]
	helo=192.168.0.102) by cmailm1.svr.pol.co.uk with esmtp (Exim 4.41)
	id 1DFrO5-0000W2-Ju; Mon, 28 Mar 2005 11:22:25 +0100
Subject: Re: Delete query takes exorbitant amount of time
From: Simon Riggs <simon@2ndquadrant.com>
To: Stephan Szabo <sszabo@megazone.bigpanda.com>
Cc: Karim Nassar <karim.nassar@acm.org>, Tom Lane <tgl@sss.pgh.pa.us>,
	Christopher Kings-Lynne <chriskl@familyhealth.com.au>,
	pgsql-performance@postgresql.org
In-Reply-To: <20050327070313.K29183@megazone.bigpanda.com>
References: <1111709457.9085.127.camel@k2.cet.nau.edu>
	<2630.1111711927@sss.pgh.pa.us>
	<1111715131.9085.174.camel@k2.cet.nau.edu>
	<3750.1111715318@sss.pgh.pa.us> <4243879B.10200@familyhealth.com.au>
	<20845.1111733900@sss.pgh.pa.us>
	<1111763448.11750.730.camel@localhost.localdomain>
	<1111787264.9168.7.camel@k2.cet.nau.edu>
	<20050326075020.P63597@megazone.bigpanda.com>
	<1111865788.9172.13.camel@k2.cet.nau.edu>
	<20050326151658.D82144@megazone.bigpanda.com>
	<1111884288.27481.6.camel@k2.cet.nau.edu>
	<20050327070313.K29183@megazone.bigpanda.com>
Content-Type: text/plain
Organization: 2nd Quadrant
Date: Mon, 28 Mar 2005 11:21:03 +0100
Message-Id: <1112005263.11750.886.camel@localhost.localdomain>
Mime-Version: 1.0
X-Mailer: Evolution 2.0.2 (2.0.2-3) 
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-new at hub.org
X-Spam-Status: No, hits=0.048 tagged_above=0 required=5 tests=AWL,
	FORGED_RCVD_HELO
X-Spam-Level: 
X-Archive-Number: 200503/600
X-Sequence-Number: 11305

On Sun, 2005-03-27 at 07:05 -0800, Stephan Szabo wrote:
> On Sat, 26 Mar 2005, Karim Nassar wrote:
> > Some improvement. Even better once it's cached. Row estimate didn't
> > change. Is this the best I can expect? Is there any other optimizations
> > I am missing?
> 
> I'm not sure, really. Running a seq scan for each removed row in the
> referenced table doesn't seem like a particularly good plan in general
> though, especially if the average number of rows being referenced isn't
> on the order of 500k per value. I don't know what to look at next though.
> 

Karim, please...

run the EXPLAIN after doing
	SET enable_seqscan = off

Thanks,

Best Regards, Simon Riggs