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
On Sep 14, 2009, at 16:55 , Josh Berkus wrote:
Users,
Please read the following two documents before posting your
performance
query here:
http://wiki.postgresql.org/wiki/Guide_to_reporting_problems
http://wiki.postgresql.org/wiki/SlowQueryQuestions
This will help other users to troubleshoo
Andrzej Zawadzki writes:
> # EXPLAIN ANALYZE SElect telekredytid from kredytyag
> WHERE TRUE
> AND kredytyag.id = 3064776
> AND NOT EXISTS
> (SELECT 1 FROM
> ( SELECT * FROM kredyty kr
> where telekredytid = 328650
> ORDER BY kr.datazaw DESC LIMIT 1 )
> kred where kred.bank = 2);
So this is the s
Josh Berkus wrote:
> Andrzej,
>
> Please post a table & index schema, and an EXPLAIN ANALYZE rather than
> just an EXPLAIN. Thanks!
>
EXPLAIN ANALYZE is taking too much time ;-) but now database is free so:
# EXPLAIN ANALYZE SElect telekredytid from kredytyag
WHERE TRUE
AND kredytyag.id = 3064
Users,
Please read the following two documents before posting your performance
query here:
http://wiki.postgresql.org/wiki/Guide_to_reporting_problems
http://wiki.postgresql.org/wiki/SlowQueryQuestions
This will help other users to troubleshoot your problems far more rapidly.
--
Josh Berkus
Po
Hi!
Yesterday I Clustered one big table (# CLUSTER kredyty USING kredyty_pkey;)
and today one query is extremely slow.
query:
SELECT telekredytid FROM kredytyag
WHERE TRUE
AND kredytyag.id = 3064776
AND NOT EXISTS
(
SELECT 1 FROM
(
SELECT * FROM kredyty kr
Andrzej,
Please post a table & index schema, and an EXPLAIN ANALYZE rather than
just an EXPLAIN. Thanks!
--
Josh Berkus
PostgreSQL Experts Inc.
www.pgexperts.com
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.post
Цитат от 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
Hi!
Yesterday I Clustered one big table (# CLUSTER kredyty USING kredyty_pkey;)
and today one query is extremely slow.
query:
SELECT telekredytid FROM kredytyag
WHERE TRUE
AND kredytyag.id = 3064776
AND NOT EXISTS
(
SELECT 1 FROM
(
SELECT * FROM kredyty kr
Цитат от 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
Joshua Rubin wrote:
Hi,
We have a very large, partitioned, table that we often need to query
from new connections, but frequently with similar queries. We have
constraint exclusion on to take advantage of the partitioning. This also
makes query planning more expensive. As a result, the CPU is fu
> 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
Hi,
Heikki Linnakangas writes:
> Joshua Rubin wrote:
>> We "hardcode" the parts of the where clause so that the prepared plan
>> will not vary among the possible partitions of the table. The only
>> values that are bound would not affect the planner's choice of table.
>
> Then you would benefit f
18 matches
Mail list logo
