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 E173E5323D for ; Fri, 25 Mar 2005 21:44:16 +0000 (GMT) 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 74109-08 for ; Fri, 25 Mar 2005 21:44:13 +0000 (GMT) Received: from mailgate2.nau.edu (mailgate2.nau.edu [134.114.96.59]) by svr1.postgresql.org (Postfix) with ESMTP id 6DDF352A66 for ; Fri, 25 Mar 2005 21:44:12 +0000 (GMT) Received: from CONVERSION-DAEMON.mailgate2.nau.edu by mailgate2.nau.edu (PMDF V6.2-X17 #30770) id <0IDX00H01GDOBO@mailgate2.nau.edu> for pgsql-performance@postgresql.org; Fri, 25 Mar 2005 14:44:13 -0700 (MST) Received: from k2.cet.nau.edu (net9-213.cet.nau.edu [134.114.9.213]) by mailgate2.nau.edu (PMDF V6.2-X17 #30770) with ESMTP id <0IDX00J66GDOZW@mailgate2.nau.edu>; Fri, 25 Mar 2005 14:44:12 -0700 (MST) Date: Fri, 25 Mar 2005 14:47:44 -0700 From: Karim Nassar Subject: Re: Delete query takes exorbitant amount of time In-reply-to: <1111763448.11750.730.camel@localhost.localdomain> To: Simon Riggs Cc: Tom Lane , Christopher Kings-Lynne , pgsql-performance@postgresql.org Message-id: <1111787264.9168.7.camel@k2.cet.nau.edu> MIME-version: 1.0 X-Mailer: Evolution 2.0.2 Content-type: text/plain Content-transfer-encoding: 7BIT 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> X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=0.103 tagged_above=0 required=5 tests=AWL, UPPERCASE_25_50 X-Spam-Level: X-Archive-Number: 200503/565 X-Sequence-Number: 11270 On Fri, 2005-03-25 at 15:10 +0000, Simon Riggs wrote: > Karim: Did this happen? If not, can you drop and re-create and confirm > that you get the WARNING? If not, we have problems. No. Nor do I think that I should. SERIAL is shortcut for INTEGER, no? I think there is some other (TBD) problem causing my big seq scan. orfs=# ALTER TABLE measurement DROP CONSTRAINT measurement_id_int_sensor_meas_type_fkey; ALTER TABLE orfs=# ALTER TABLE ONLY measurement ADD CONSTRAINT measurement_id_int_sensor_meas_type_fkey orfs-# FOREIGN KEY (id_int_sensor_meas_type) REFERENCES int_sensor_meas_type(id_int_sensor_meas_type); ALTER TABLE orfs=# The add constraint statement comes directly from a pg_dump. For clarity, the table/indexes were created as such: CREATE TABLE int_sensor_meas_type( id_int_sensor_meas_type SERIAL PRIMARY KEY, id_sensor integer NOT NULL REFERENCES sensor, id_meas_type integer NOT NULL REFERENCES meas_type UNIQUE); CREATE TABLE measurement ( id_measurement SERIAL PRIMARY KEY, id_int_sensor_meas_type integer NOT NULL REFERENCES int_sensor_meas_type, datetime timestamp WITH TIME ZONE NOT NULL, value numeric(15,5) NOT NULL, created timestamp with time zone NOT NULL DEFAULT now(), created_by TEXT NOT NULL REFERENCES public.person(id_person)); CREATE INDEX measurement__id_int_sensor_meas_type_idx ON measurement(id_int_sensor_meas_type); Regards, -- Karim Nassar Department of Computer Science Box 15600, College of Engineering and Natural Sciences Northern Arizona University, Flagstaff, Arizona 86011 Office: (928) 523-5868 -=- Mobile: (928) 699-9221