.4): http://explain.depesz.com/s/tw8
thanks again for the help.
Julie
-Original Message-
From: t...@fuzzy.cz [mailto:t...@fuzzy.cz]
Sent: Monday, March 21, 2011 11:33 AM
To: Davenport, Julie
Cc: Merlin Moncure; Tomas Vondra; pgsql-general@postgresql.org
Subject: RE: [GENERAL] query taking m
On 22 Mar 2011, at 24:20, F. BROUARD / SQLpro wrote:
> Try this :
>
> 1) rewrite your query as is :
Indeed, a join is probably more efficient than a big IN-list. Good point ;)
>
> select course_id AS EXTERNAL_COURSE_KEY,
> user_id AS EXTERNAL_PERSON_KEY,
> 'Student' AS ROLE,
>
Try this :
1) rewrite your query as is :
select course_id AS EXTERNAL_COURSE_KEY,
user_id AS EXTERNAL_PERSON_KEY,
'Student' AS ROLE,
'Y' AS AVAILABLE_IND
from course_user_link AS CUL
INNER JOIN course_control AS CC
ON CUL.course_id = CC.course_id
where
>>-Original Message-
>>From: Merlin Moncure [mailto:mmonc...@gmail.com]
>>Sent: Friday, March 18, 2011 1:18 PM
>>To: Davenport, Julie
>>Cc: Tomas Vondra; pgsql-general@postgresql.org
>>Subject: Re: [GENERAL] query taking much longer since Postgres 8.4 upgrade
> On Mon, Mar 21, 2011 at 11:32 AM, wrote:
>>> Incredible! Setting enable_nestloop off temporarily for the run of
>>> this
>>> script made it run in less than a minute (had been running in 10 or 11
>>> minutes). I think you have found a solution for many of my slow
>>> running
>>> scripts that
On Mon, Mar 21, 2011 at 11:32 AM, wrote:
>> Incredible! Setting enable_nestloop off temporarily for the run of this
>> script made it run in less than a minute (had been running in 10 or 11
>> minutes). I think you have found a solution for many of my slow running
>> scripts that use these same
> Incredible! Setting enable_nestloop off temporarily for the run of this
> script made it run in less than a minute (had been running in 10 or 11
> minutes). I think you have found a solution for many of my slow running
> scripts that use these same type of joins. Thanks again.
> Julie
Nice. C
Dne 18.3.2011 19:18, Merlin Moncure napsal(a):
> On Fri, Mar 18, 2011 at 10:42 AM, Davenport, Julie
> wrote:
>> This helped, is now down from 14.9 min to 10.9 min to run the entire script.
>> Thanks.
>
> can you try disabling nestloop and see what happens? In the session,
> before running th
On Fri, Mar 18, 2011 at 10:42 AM, Davenport, Julie wrote:
> This helped, is now down from 14.9 min to 10.9 min to run the entire script.
> Thanks.
can you try disabling nestloop and see what happens? In the session,
before running the query, isssue:
set enable_nestloop = false;
merlin
--
S
Dne 18.3.2011 16:42, Davenport, Julie napsal(a):
> This helped, is now down from 14.9 min to 10.9 min to run the entire script.
> Thanks.
Still, it's way slower than the 8.0 :-(
regards
Tomas
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscri
This helped, is now down from 14.9 min to 10.9 min to run the entire script.
Thanks.
Dne 17.3.2011 19:29, Davenport, Julie napsal(a):
I have not yet had time to try Tomas' suggestion of bumping up the
work_mem first (trying to figure out how to do that from within a
col
Dne 17.3.2011 19:29, Davenport, Julie napsal(a):
> I have not yet had time to try Tomas' suggestion of bumping up the work_mem
> first (trying to figure out how to do that from within a coldfusion script).
> Many thanks for all your help guys!
Well, just execute this 'SQL query' just like the o
s.
Progress! I have not yet had time to try Tomas' suggestion of bumping up the
work_mem first (trying to figure out how to do that from within a coldfusion
script). Many thanks for all your help guys!
Julie
-----Original Message-
From: Pavel Stehule [mailto:pavel.steh...@gmail.com]
Sen
ulie
> Subject: Re: [GENERAL] query taking much longer since Postgres 8.4 upgrade
>
> Dne 16.3.2011 22:31, Pavel Stehule napsal(a):
>> 2011/3/16 Tomas Vondra :
>>> Dne 16.3.2011 21:38, Davenport, Julie napsal(a):
>>>> OK, I did the explain analyze on both
4
> (1 row)
>
> srn_mst=# show seq_page_cost;
> seq_page_cost
> ---
> 1
> (1 row)
>
> srn_mst=# show work_mem;
> work_mem
> --
> 1MB
> (1 row)
>
> Thanks,
> Julie
>
>
>
> -Original Message-
> From: Tomas Vondra [mailto:t.
Dne 16.3.2011 22:31, Pavel Stehule napsal(a):
> 2011/3/16 Tomas Vondra :
>> Dne 16.3.2011 21:38, Davenport, Julie napsal(a):
>>> OK, I did the explain analyze on both sides (using a file for output
>>> instead) and used the tool you suggested.
>>>
>>> 8.0 - http://explain.depesz.com/s/Wam
>>> 8.4
2011/3/16 Tomas Vondra :
> Dne 16.3.2011 21:38, Davenport, Julie napsal(a):
>> OK, I did the explain analyze on both sides (using a file for output
>> instead) and used the tool you suggested.
>>
>> 8.0 - http://explain.depesz.com/s/Wam
>> 8.4 - http://explain.depesz.com/s/asJ
>
> Great, that's ex
Dne 16.3.2011 21:38, Davenport, Julie napsal(a):
> OK, I did the explain analyze on both sides (using a file for output instead)
> and used the tool you suggested.
>
> 8.0 - http://explain.depesz.com/s/Wam
> 8.4 - http://explain.depesz.com/s/asJ
Great, that's exactly what I asked for. I'll rep
;
>>
>>
>> -Original Message-
>> From: Merlin Moncure [mailto:mmonc...@gmail.com]
>> Sent: Wednesday, March 16, 2011 1:37 PM
>> To: Davenport, Julie
>> Cc: pgsql-general@postgresql.org
>> Subject: Re: [GENERAL] query taking much longer since Postgr
ocale for time formatting
>
> Am I looking in the wrong place? Thanks much,
> Julie
>
>
> Julie A. Davenport
> julie.davenp...@ctcd.edu
>
>
>
>
> -Original Message-
> From: Merlin Moncure [mailto:mmonc...@gmail.com]
> Sent: Wednesday, March 16, 201
On Wed, Mar 16, 2011 at 10:49 AM, Davenport, Julie wrote:
> When I run the following query in Postgres 8.0, it runs in 61,509.372 ms
>
>
>
> When I run it in Postgres 8.4, it runs in 397,857.472 ms
>
>
>
> Here is the query:
>
>
>
> select
>
> course_id AS EXTERNAL_COURSE_KEY,
>
> user_id AS EXTER
> When I run the following query in Postgres 8.0, it runs in 61,509.372 ms
>
> When I run it in Postgres 8.4, it runs in 397,857.472 ms
As Andrew already pointed out, we need to se EXPLAIN ANALYZE output from
both machines to see why this happens. Are you running both queries on the
same data, or
Output of explain (and as likely, explain analyze) for this would be
helpful.
A
On Wed, Mar 16, 2011 at 10:49:24AM -0500, Davenport, Julie wrote:
> When I run the following query in Postgres 8.0, it runs in 61,509.372 ms
>
> When I run it in Postgres 8.4, it runs in 397,857.472 ms
>
> Here is t
23 matches
Mail list logo
