Цитат от Віталій Тимчишин :
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
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.
BTW: In this case, increasing shared buffers may help. At least this will
prev
Цитат от 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
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 a_gar_prod_r gr on
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
>>> syste
Цитат от 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
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 execution, or there is some
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
> 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
Цитат от 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
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 to go
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
13 matches
Mail list logo
