On Wed, Dec 17, 2008 at 9:18 AM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Tue, Dec 16, 2008 at 2:32 PM, Jaime Casanova
> <jcasanov@systemguards.com.ec> wrote:
>> we have a some bad queries (developers are working on that), some of
>> them run in 17 secs and that is the average but when analyzing logs i
>> found that from time to time some of them took upto 3 mins (the same
>> query that normally runs in 17secs).
>>
>> so my question is: how could i look for contention problems?
>
> Is it the exact same query?
is the exact query... i think it will be removed later today because
is a bad query anyway... but my fear is that something like happens
even with good ones...
maybe chekpoints could be the problem?
i have 8.3.5 and condigured checkpoint_timeout in 15 minutes,
chekpoint_segments 6 and checkpoint_completion_target to 0.5
i'm putting log_checkpoints to on, but should be good if there is way
to analyze them better than looking through the log
> Sometimes you might find that the query
> plan changes depending on the particular values you have in there; it
> is worth running "EXPLAIN ANALYZE" to look for such cases.
>
don't think that could happen in this query, because there is no way
it will choose something better than seqscan
> You might also want to look at pg_locks.
>
Only Shared ones...
PS: more info about my system (sorry for don't giving it in the first post)
2 PROCESSORS Xeon(R) CPU E5430 @ 2.66GHz with 4 cores each
18Gb in Ram (4gb in shared_buffers, 4mb in work_mem)
the db size is 2gb (reported by pg_database_size)
max. concurrent connections seen until now: 256
--
Atentamente,
Jaime Casanova
Soporte y capacitación de PostgreSQL
Asesoría y desarrollo de sistemas
Guayaquil - Ecuador
Cel. +59387171157