Hi everybody,
thanks for the so many responses. :)
> On Thu, Apr 19, 2012 at 3:44 AM, Josh Berkus
>>> 7500ms
>>> http://explain.depesz.com/s/
>> This plan seems very odd -- doing individual index lookups on 2.8m rows
>> is not standard planner behavior. Can you confirm that all of your
>> othe
On Thu, Apr 19, 2012 at 3:44 AM, Josh Berkus
>> 7500ms
>> http://explain.depesz.com/s/
> This plan seems very odd -- doing individual index lookups on 2.8m rows
> is not standard planner behavior. Can you confirm that all of your
> other query cost parameters are the defaults?
This similat to th
On 4/17/12 2:49 AM, Istvan Endredy wrote:
> Hi,
>
> thanks for the suggestion, but it didn't help. We have tried it earlier.
>
> 7500ms
> http://explain.depesz.com/s/ctn
This plan seems very odd -- doing individual index lookups on 2.8m rows
is not standard planner behavior. Can you confirm tha
How about
with par_ as (select * from product_parent where parent_name like 'aa%' )
select distinct product_code from product p_
inner join par_ on p_.parent_id=par_.id
limit 2
?
2012/4/3 Istvan Endredy
> Hi,
>
> i've ran into a planning problem.
>
>
> select distinct product_code from produc
Hi,
thanks for the suggestion, but it didn't help. We have tried it earlier.
7500ms
http://explain.depesz.com/s/ctn
ALTER TABLE product_parent ALTER COLUMN parent_name SET STATISTICS 1000;
ALTER TABLE product ALTER COLUMN parent_id SET STATISTICS 1000;
ANALYZE product_parent;
ANALYZE product;
q
could you try to set the statistics parameter to 1000 (ALTER TABLE SET
STATISTICS) for these tables, then run analyze and try again?
--
View this message in context:
http://postgresql.1045698.n5.nabble.com/bad-planning-with-75-effective-cache-size-tp5620363p5642356.html
Sent from the PostgreSQL -
Hi Kevin,
thanks for the suggestion. It was my 1st task to try this after Easter. :)
Sorry to say this parameter doesn't help:
bad planning:
set cpu_tuple_cost = '0.05';
set effective_cache_size to '6GB';
1622ms
http://explain.depesz.com/s/vuO
or
set cpu_tuple_cost = '0.01';
set effective_cache
Istvan Endredy wrote:
> i've ran into a planning problem.
> If effective_cache_size has a greater value (6GB), this select has
> a bad planning and long query time (2000ms):
Could you try that configuration with one change and let us know how
it goes?:
set cpu_tuple_cost = '0.05';
I've s
