Hi,
I'm using Postgresql 8.3.6 under Freebsd 7.1.
After a fresh restore of a customer dump (running version 8.2.7 at the
moment), a rather big query executes in about 30 seconds. As soon as I
run ANALYZE, it is instantly 4-5 times slower. I could check that
multiples times.
Here is the EXPLAIN
In response to Philippe Lang philippe.l...@attiksystem.ch:
I'm using Postgresql 8.3.6 under Freebsd 7.1.
After a fresh restore of a customer dump (running version 8.2.7 at the
moment), a rather big query executes in about 30 seconds. As soon as I
run ANALYZE, it is instantly 4-5 times
Bill Moran wmo...@potentialtech.com writes:
I opened one of those links figuring I'd take a few minutes to see if I could
muster up some advice ... and just started laughing ... definitely not the
type of query that one can even understand in just a few minutes!
You might consider setting
In response to Philippe Lang philippe.l...@attiksystem.ch:
I'm using Postgresql 8.3.6 under Freebsd 7.1.
After a fresh restore of a customer dump (running version 8.2.7 at the
moment), a rather big query executes in about 30 seconds. As soon as I
run ANALYZE, it is instantly 4-5 times
Oh, the other thing you could try experimenting with are these two parameters.
Your query has *way* more tables than the default values for these so you
would have to raise them substantially. Given that the query was running in
30s you may find that this increases the planning time by more time
hi
it's look better with explain.depesz.com :) you can easily find that
in before it uses index scan and in after it uses seq
before:
http://explain.depesz.com/s/RC
after:
http://explain.depesz.com/s/nm
try as mentioned before to change costs
Best regards,
Sebastian Pawłowski
pgsql-general-ow...@postgresql.org wrote:
In response to Philippe Lang philippe.l...@attiksystem.ch:
I'm using Postgresql 8.3.6 under Freebsd 7.1.
After a fresh restore of a customer dump (running version 8.2.7 at
the moment), a rather big query executes in about 30 seconds. As
soon as I
In response to Philippe Lang philippe.l...@attiksystem.ch:
[snip]
Anyway, the real reason I posted -- I doubt if anyone will be able to
make sense of a query plan that complex without the actual query, so
you'll probably want to post it as well.
:) What? I thought you would read that
Philippe Lang philippe.l...@attiksystem.ch writes:
A small question here: solde_po is an SQL function (not PLPGSQL). Is it
inlined in the parent query before the whole query execution plan is
calculated?
You should be able to tell that by inspecting the filter conditions
in the ANALYZE output.
