pg.ddx.io  pgsql-performance@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Stephan Szabo <sszabo@megazone.bigpanda.com>
To: Karim Nassar <karim.nassar@acm.org>
Cc: Simon Riggs <simon@2ndquadrant.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Christopher Kings-Lynne <chriskl@familyhealth.com.au>
Cc: pgsql-performance@postgresql.org
Subject: Re: Delete query takes exorbitant amount of time
Date: Sun, 27 Mar 2005 07:05:38 -0800 (PST)
Message-ID: <20050327070313.K29183@megazone.bigpanda.com> (raw)
In-Reply-To: <1111884288.27481.6.camel@k2.cet.nau.edu>
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>


On Sat, 26 Mar 2005, Karim Nassar wrote:

> On Sat, 2005-03-26 at 15:18 -0800, Stephan Szabo wrote:
> > On Sat, 26 Mar 2005, Karim Nassar wrote:
> >
> > > On Sat, 2005-03-26 at 07:55 -0800, Stephan Szabo wrote:
> > > > That seems like it should be okay, hmm, what does something like:
> > > >
> > > > PREPARE test(int) AS SELECT 1 from measurement where
> > > > id_int_sensor_meas_type = $1 FOR UPDATE;
> > > > EXPLAIN ANALYZE EXECUTE TEST(1);
> > > >
> > > > give you as the plan?
> > >
> > >                                                       QUERY PLAN
> > > -----------------------------------------------------------------------------------------------------------------------
> > >  Seq Scan on measurement  (cost=0.00..164559.16 rows=509478 width=6)
> > >                           (actual time=11608.402..11608.402 rows=0 loops=1)
> > >                           Filter: (id_int_sensor_meas_type = $1)
> > >  Total runtime: 11608.441 ms
> > > (3 rows)
> >
> > Hmm, has measurement been analyzed recently?  You might want to see if
> > raising the statistics target on measurement.id_int_sensor_meas_type and
> > reanalyzing changes the estimated rows down from 500k.
>
> orfs=# ALTER TABLE measurement ALTER COLUMN id_int_sensor_meas_type SET STATISTICS 1000;
> ALTER TABLE
> orfs=# VACUUM FULL ANALYZE VERBOSE;
> <snip>
> INFO:  free space map: 52 relations, 13501 pages stored; 9760 total pages needed
> DETAIL:  Allocated FSM size: 1000 relations + 300000 pages = 1864 kB shared memory.
> VACUUM
> orfs=# PREPARE test(int) AS SELECT 1 from measurement where
> orfs-# id_int_sensor_meas_type = $1 FOR UPDATE;
> PREPARE
> orfs=# EXPLAIN ANALYZE EXECUTE TEST(1);
>                                                      QUERY PLAN
> ---------------------------------------------------------------------------------------------------------------------
>  Seq Scan on measurement  (cost=0.00..164559.16 rows=509478 width=6) (actual time=8948.452..8948.452 rows=0 loops=1)
>    Filter: (id_int_sensor_meas_type = $1)
>  Total runtime: 8948.494 ms
> (3 rows)
>
> orfs=# EXPLAIN ANALYZE EXECUTE TEST(1);
>                                                      QUERY PLAN
> ---------------------------------------------------------------------------------------------------------------------
>  Seq Scan on measurement  (cost=0.00..164559.16 rows=509478 width=6) (actual time=3956.616..3956.616 rows=0 loops=1)
>    Filter: (id_int_sensor_meas_type = $1)
>  Total runtime: 3956.662 ms
> (3 rows)
>
>
>
> 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.




view thread (60+ messages)  latest in thread

Message-ID: <20050327070313.K29183@megazone.bigpanda.com>
Permalink:  ../20050327070313.K29183@megazone.bigpanda.com/
Also on:    postgresql.org/message-id/20050327070313.K29183@megazone.bigpanda.com

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-performance@postgresql.org
  Cc: sszabo@megazone.bigpanda.com, karim.nassar@acm.org, simon@2ndquadrant.com, tgl@sss.pgh.pa.us, chriskl@familyhealth.com.au
  Subject: Re: Delete query takes exorbitant amount of time
  In-Reply-To: <20050327070313.K29183@megazone.bigpanda.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox