On Thu, Apr 19, 2012 at 3:44 AM, Josh Berkus j...@agliodbs.com
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
Hi everybody,
thanks for the so many responses. :)
On Thu, Apr 19, 2012 at 3:44 AM, Josh Berkus j...@agliodbs.com
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
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 istvan.endr...@gmail.com
Hi,
i've ran into a planning problem.
select distinct
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 that all
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;
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
Hi,
i've ran into a planning problem.
Dedicated PostgreSQL Server:
PostgreSQL 9.1.3 on x86_64-unknown-linux-gnu, compiled by gcc (GCC) 4.1.2
20080704 (Red Hat 4.1.2-46), 64-bit
Memory: 8GB
4CPUs
The problem is reduced to the following: there are 2 tables:
-product (3millions rows, 1GB)
Istvan Endredy istvan.endr...@gmail.com 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
