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 writes:
-> Seq Scan on corpus toplevel
(cost=0
Hi everybody,
I'm wondering why a DELETE statement of mine does not make use of
defined indexes on the tables.
I have the following tables which are linked as such: component ->
rank -> node -> corpus;
Now I want to delete all entries in component by giving a list of
corpus ids.
The q
Hi,
using this strategy to study the overhead of EXPLAIN ANALYZE was very
insightful. Apparently, measuring the performance of the query plan
introduced a overhead of more than 10 seconds in the query I was
looking at.
Thanks,
Viktor
Am 24.04.2008 um 19:05 schrieb PFC:
Do you mean, that
Hi Tom,
The cost of the inner-most Nested Loop is 27 ms, but the total cost
of
the Materialize operator is 666 ms (9250 loops * 0.072 ms per
iteration). So, Materialize introduces more than 10x overhead.
Not hardly. Had the Materialize not been there, we'd have executed
the inner nestloop
Hi,
I'm having trouble understanding the cost of the Materialize
operator. Consider the following plan:
Nested Loop (cost=2783.91..33217.37 rows=78634 width=44) (actual
time=77.164..2478.973 rows=309 loops=1)
Join Filter: ((rank2.pre <= rank5.pre) AND (rank5.pre <=
rank2.post))
