I should have looked at the analyzed plan first. The culprit for the
slow query were trigger function calls on foreign keys.
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 =
>> 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: