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)
Increasing the default_statistics_target to 1000 did not help.
It just make the vacuum full analyze to take longer to complete.
Here is the output :
CCM=# VACUUM FULL ANALYZE ;
VACUUM
CCM=# explain ANALYZE SELECT distinct C.cod_couleur_panneau,
C.cod_couleur_panneau, cast ('LM05' as varchar), ca
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
-
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
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
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
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
