Цитат от Віталій Тимчишин :
May be you have very bad disk access times (e.g. slow random access)? In
this case everything should be OK while data in cache and awful, when not.
Could you check disk IO speed && IO wait while doing slow & fast query.
No, I think all is ok with disks. On my test
Цитат от Scott Marlowe :
2009/9/14 :
Also I waited to the end of this query to gather info for explain analyze..
It is it:
explain analyze select d.ids from a_doc d join a_sklad s on
(d.ids=s.ids_doc) join a_nomen n on (n.ids=s.ids_num) join a_nom_gr nmgr
on (nmgr.ids=n.ids_grupa) join
Цитат от Robert Haas :
2009/9/14 :
Цитат от Robert Haas :
2009/9/14 :
It seems there's something very wrong - the plans are "equal" but in the
first case the results (actual time) are multiplied by 100. Eithere there
is some sort of cache (so the second execution is much faster), or the
s
Цитат от Robert Haas :
2009/9/14 :
It seems there's something very wrong - the plans are "equal" but in the
first case the results (actual time) are multiplied by 100. Eithere there
is some sort of cache (so the second execution is much faster), or the
system was busy during the first executio
Hi ,
Hi Tom,
Yes, 24 is relative ok ( the real number is 20).
And the statistic target for the database is 800 at the moment. If
needet I can set it to 1000 ( the maximum).
Also I waited to the end of this query to gather info for explain analyze.
It is it:
explain analyze select d.ids f
Цитат от Tom Lane :
zz...@mail.bg writes:
I am running a relativ complex query on pg 8.3.5 and have (possible)
wrong query plan.
...
If I run the query without thle last part : and n.num like '191%'
it work ok as speed ~ 30 sec on not very big db.
If I run the full query it take very long time
Hi,
I am running a relativ complex query on pg 8.3.5 and have (possible)
wrong query plan.
My select :
explain analyze select d.ids from a_doc d join a_sklad s on
(d.ids=s.ids_doc) join a_nomen n on (n.ids=s.ids_num) join a_nom_gr
nmgr on (nmgr.ids=n.ids_grupa) join a_gar_prod_r gr
