From: | Gaetano Mendola <mendola(at)bigfoot(dot)com> |
---|---|
To: | Marius Andreiana <mandreiana(at)rdslink(dot)ro> |
Subject: | Re: NOT IN query takes forever |
Date: | 2004-08-03 17:28:27 |
Message-ID: | 410FCB3B.5050300@bigfoot.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-performance |
Marius Andreiana wrote:
> On Tue, 2004-08-03 at 08:05 -0400, Merlin Moncure wrote:
>
>>>Trying to run this query:
>>>EXPLAIN ANALYSE
>>>select * FROM trans
>>>WHERE query_id NOT IN (select query_id FROM query)
>>>
>>>but it will remain like that forever (cancelled after 30 min).
>>
>>explain analyze actually runs the query to do timings. Just run explain
>>and see what you come up with. More than likely there is a nestloop in
>>there which is causing the long query time.
>>
>>Try bumping up shared buffers some and sort mem as much as you safely
>>can.
>
> Thank you, that did it!
>
> With
> shared_buffers = 3000 # min 16, at least max_connections*2, 8KB each
> sort_mem = 128000 # min 64, size in KB
128 MB for sort_mem is too much, consider that in this way each backend can
use 128 MB for sort operations...
Also shared_buffers = 3000 means 24MB that is not balanced with the 128MB
needed for sort...
Try to bump up 128 MB for shared_buffer ( may be you need to instruct your
OS to allow that ammount of shared memory usage ) and 24MB for sort_mem.
Regards
Gaetano Mendola
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Treat | 2004-08-03 18:39:30 | Re: PostgreSQL, GnuCash |
Previous Message | Jim C. Nasby | 2004-08-03 16:18:42 | Re: Casting timestamp with time zone to varchar automatically |
From | Date | Subject | |
---|---|---|---|
Next Message | Martin Foster | 2004-08-03 18:05:04 | Performance Bottleneck |
Previous Message | Merlin Moncure | 2004-08-03 16:10:04 | Re: NOT IN query takes forever |