Re: Indexes not used in DELETE

From: Viktor Rosenfeld
Subject: Re: Indexes not used in DELETE
Date: ,
Msg-id: A24EBF1D-F70A-4300-B27E-BCD86CBAF828@informatik.hu-berlin.de
(view: Whole thread, Raw)
In response to: Re: Indexes not used in DELETE  (Tom Lane)
List: pgsql-performance

Hi Tom,

I should have looked at the analyzed plan first. The culprit for the
slow query were trigger function calls on foreign keys.

Ciao,
Viktor

Am 08.05.2009 um 01:06 schrieb Tom Lane:

> Viktor Rosenfeld <-berlin.de> writes:
>>                            ->  Seq Scan on corpus toplevel
>> (cost=0.00..1.39 rows=1 width=54)
>>                                  Filter: (top_level AND (id =
>> 25::numeric))
>
>> Specifically, I'm wondering why the innermost scan on corpus
>> (toplevel) does not use the index idx_corpus__toplevel
>
> The cost estimate indicates that there are so few rows in corpus
> that an indexscan would be a waste of time.
>
>> and why the
>> join between corpus (toplevel) and corpus (child) is not a merge join
>> using the index corpus_pre_key to access the child table.
>
> Same answer.  Populate the table and the plan will change.
>
>             regards, tom lane
>
> --
> Sent via pgsql-performance mailing list (
> )
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-performance



pgsql-performance by date:

From: Tom Lane
Date:
Subject: Re: Statistics use with functions
From: Robert Haas
Date:
Subject: Re: Transparent table partitioning in future version of PG?