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 69F4F53377
	for <pgsql-performance-postgresql.org@localhost.postgresql.org>;
	Mon, 28 Mar 2005 17:27:43 +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 98115-01
	for <pgsql-performance-postgresql.org@localhost.postgresql.org>;
	Mon, 28 Mar 2005 16:27:42 +0000 (GMT)
Received: from megazone.bigpanda.com (megazone.bigpanda.com [64.147.171.210])
	by svr1.postgresql.org (Postfix) with ESMTP id E9FA15332C
	for <pgsql-performance@postgresql.org>;
	Mon, 28 Mar 2005 17:27:39 +0100 (BST)
Received: by megazone.bigpanda.com (Postfix, from userid 1001)
	id 6A79735BDB; Mon, 28 Mar 2005 08:27:36 -0800 (PST)
Received: from localhost (localhost [127.0.0.1])
	by megazone.bigpanda.com (Postfix) with ESMTP
	id 6896435BD0; Mon, 28 Mar 2005 08:27:36 -0800 (PST)
Date: Mon, 28 Mar 2005 08:27:36 -0800 (PST)
From: Stephan Szabo <sszabo@megazone.bigpanda.com>
To: Karim A Nassar <Karim.Nassar@NAU.EDU>
Cc: Simon Riggs <simon@2ndquadrant.com>, Tom Lane <tgl@sss.pgh.pa.us>,
	Christopher Kings-Lynne <chriskl@familyhealth.com.au>,
	pgsql-performance@postgresql.org
Subject: Re: Delete query takes exorbitant amount of time
In-Reply-To: <Pine.SOL.4.21.0503280328180.382-100000@coruscant.cet.nau.edu>
Message-ID: <20050328082645.X95787@megazone.bigpanda.com>
References: <Pine.SOL.4.21.0503280328180.382-100000@coruscant.cet.nau.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Virus-Scanned: by amavisd-new at hub.org
X-Spam-Status: No, hits=0.005 tagged_above=0 required=5 tests=AWL
X-Spam-Level: 
X-Archive-Number: 200503/603
X-Sequence-Number: 11308

On Mon, 28 Mar 2005, Karim A Nassar wrote:

> On Mon, 28 Mar 2005, Simon Riggs wrote:
> > run the EXPLAIN after doing
> > 	SET enable_seqscan = off
>
> The results I previously supplied were searching for a non-existent
> value, so I have provided output for both cases.
>
> ***
> *** Searching for non-existent value
> ***
>
> orfs=# PREPARE test2(int) AS SELECT 1 from measurement where
> orfs-# id_int_sensor_meas_type = $1 FOR UPDATE;
> PREPARE
> orfs=#  EXPLAIN ANALYZE EXECUTE TEST2(1);
>  QUERY PLAN
> --------------------------------------------------------------------------
>  Seq Scan on measurement
>     (cost=0.00..164559.16 rows=509478 width=6)
>     (actual time=6421.849..6421.849 rows=0 loops=1)
>    Filter: (id_int_sensor_meas_type = $1)
>  Total runtime: 6421.917 ms
> (3 rows)
>
> orfs=#  SET enable_seqscan = off;

I think you have to prepare with enable_seqscan=off, because it effects
how the query is planned and prepared.