Thanks for the advice Tom !
Setting enable_nestloop = off did improve the query a much better way
than setting enable_seqscan to off.
It does not screw the costs either (I had very odd costs with
enable_seqscan to off like this : Nested Loop
(cost=41665.30..42197.96 rows=1 width=96)
<[EMAIL PROTECTED]> writes:
> I was able to improve response time by seting enable_seqscan to off
enable_nestloop = off would probably be a saner choice, at least for
this particular query.
regards, tom lane
---(end of broadcast)---
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of
> [EMAIL PROTECTED]
> Subject: Re: [PERFORM] Execution plan changed after upgrade
> from 7.3.9 to 8.2.3
>
>
> Increasing the default_statistics_target to 1000 did not help.
> It just make the vacuum
65 loops=280)
Filter: (((idmagasin)::text = '011'::text) AND ((idoav)::text =
'PC_PLACARD'::text) AND (
autorise = 1))
-> Seq Scan on lm05_t_composition e (cost=0.00..14.82 rows=573 width=4)
(actual time=0.010..0.452 r
ows=573 loops=280)
Filter: (nb_vantaux >= 2)
-> S
All planner types were enabled.
CCM=# select * from pg_settings where name like 'enable_%';
name| setting | unit | category
| short_desc | extra_desc |
context | vartype | source | min_val | max_val
-
[EMAIL PROTECTED] wrote:
> Here it is :
>
> CCM=# SHOW enable_mergejoin;
> enable_mergejoin
> --
> on
> (1 row)
Sorry, my question was more general. Do you have _any_ of the planner
types disabled? Try also enable_indexscan, etc; maybe
select * from pg_settings where name like
[EMAIL PROTECTED] wrote:
Thanks for the update.
The following did not change anything in the execution plan
ALTER TABLE lm05_t_tarif_panneau ALTER COLUMN lrg_min SET STATISTICS 1000
ALTER TABLE lm05_t_tarif_panneau ALTER COLUMN lrg_max SET STATISTICS 1000
ANALYZE lm05_t_tarif_panneau
Hmm - so
Here it is :
CCM=# SHOW enable_mergejoin;
enable_mergejoin
--
on
(1 row)
CCM=#
Alvaro Herrera wrote:
> [EMAIL PROTECTED] wrote:
>
>> I have attached the requested information.
>>
>> You will see that the query is quite messy and could be easily improved.
>> Unfortunately, i
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of
> [EMAIL PROTECTED]
> Subject: Re: [PERFORM] Execution plan changed after upgrade
> from 7.3.9 to 8.2.3
>
> The following did not change anything in the execution plan
>
> ALTER TABLE lm05_t_tarif_p
[EMAIL PROTECTED] wrote:
> I have attached the requested information.
>
> You will see that the query is quite messy and could be easily improved.
> Unfortunately, it came from a third party application and we do not have
> access to the source code.
There are only nested loops and hash joins, w
Thanks for the update.
The following did not change anything in the execution plan
ALTER TABLE lm05_t_tarif_panneau ALTER COLUMN lrg_min SET STATISTICS 1000
ALTER TABLE lm05_t_tarif_panneau ALTER COLUMN lrg_max SET STATISTICS 1000
ANALYZE lm05_t_tarif_panneau
I was able to improve response time
[EMAIL PROTECTED] wrote:
I have attached the requested information.
You will see that the query is quite messy and could be easily improved.
Unfortunately, it came from a third party application and we do not have
access to the source code.
-> Hash Join (cost=6.31..3056.17 rows=116 width=47
I have attached the requested information.
You will see that the query is quite messy and could be easily improved.
Unfortunately, it came from a third party application and we do not have
access to the source code.
Thanks for your help,
Best Regards,
Vincent
Michael Fuhr wrote:
> On Tue, M
On Tue, Mar 13, 2007 at 09:19:47AM +0100, [EMAIL PROTECTED] wrote:
> Is there an option in the 8.2.3 to change in order to have the same
> execution plan than before ?
Let's see if we can figure out why 8.2.3 is choosing a bad plan.
Have you run ANALYZE on the tables in 8.2.3? Could you post the
Hello,
I have upgraded from 7.3.9 to 8.2.3 and now the application that is
using Postgres is really slow.
Using pgfouine, I was able to identify a SQL select statement that was
running in 500 ms before and now that is running in more than 20 seconds !
The reason is that the execution plan is
15 matches
Mail list logo
