| 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: | Whole Thread | Raw Message | 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 |