pg.ddx.io  pgsql-performance@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Volkan YAZICI <yazicivo@ttmail.com>
To: Richard Huxton <dev@archonet.com>
Cc: pgsql-performance@postgresql.org
Subject: Re: Unexpectedly Long DELETE Wait
Date: Thu, 07 Aug 2008 17:36:28 +0300
Message-ID: <877iasvqmr.fsf@alamut.mobiliz.com.tr> (raw)
In-Reply-To: <489AAB08.9080409@archonet.com>
References: <874p5xwe3g.fsf@alamut.mobiliz.com.tr>
	<489AAB08.9080409@archonet.com>

On Thu, 07 Aug 2008, Richard Huxton <dev@archonet.com> writes:
> Volkan YAZICI wrote:
>>   DELETE FROM mugpsreglog
>>         WHERE NOT EXISTS (SELECT 1
>>                             FROM mueventlog
>>                            WHERE mueventlog.eventlogid = mugpsreglog.eventlogid);
>>
>>    Seq Scan on mugpsreglog  (cost=0.00..57184031821394.73 rows=6590986 width=6)
>>      Filter: (NOT (subplan))
>>         SubPlan
>>              ->  Seq Scan on mueventlog  (cost=0.00..4338048.00 rows=1 width=0)
>>              Filter: (eventlogid = $0)
>
> Ouch - look at the estimated cost on that!
>
>> And there isn't any constraints (FK/PK), triggers, indexes, etc. on any
>> of the tables. (We're in the phase of a migration, many DELETE commands
>> similar to above gets executed to relax constraints will be introduced.)
>
> Well there you go. Add an index on eventlogid for mugpsreglog.

Hrm... Adding an INDEX on "eventlogid" column of "mueventlog" table
solved the problem. Anyway, thanks for your kindly help.

> Alternatively, if you increased your work_mem that might help. Try SET
> work_mem='64MB' (or even higher) before running the explain and see if it tries
> a materialize. For situations like this where you're doing big one-off queries
> you can afford to increase resource limits.

None of 64MB, 128MB, 256MB and 512MB settings make a change in the query
plan.


Regards.



view thread (3+ messages)

Message-ID: <877iasvqmr.fsf@alamut.mobiliz.com.tr>
Permalink:  ../877iasvqmr.fsf@alamut.mobiliz.com.tr/
Also on:    postgresql.org/message-id/877iasvqmr.fsf@alamut.mobiliz.com.tr

 · 

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: yazicivo@ttmail.com, dev@archonet.com
  Subject: Re: Unexpectedly Long DELETE Wait
  In-Reply-To: <877iasvqmr.fsf@alamut.mobiliz.com.tr>

* 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