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 <rosenfel@xxxxxxxxxxxxxxxxxxxxxxx> 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 (pgsql-performance@xxxxxxxxxxxxxx
)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
--
Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
