[ADMIN] problem on table statistics

2012-01-09 Thread Silvio Brandani
In the last few hours we get a problem with following query in Production database : select * from "001".mov_con where number in ( select number from "001".mov_con where abs(amount-total_amo)>0.1) ; The correct plan should be QUERY PLAN -

Re: [ADMIN] problem on table statistics

2012-01-09 Thread Szymon Guz
On 9 January 2012 15:41, Silvio Brandani wrote: > > In the last few hours we get a problem with following query in Production > database : > > select * from "001".mov_con where number in ( select number from > "001".mov_con where abs(amount-total_amo)>0.1) ; > > The correct plan should be > >

Re: [ADMIN] problem on table statistics

2012-01-09 Thread Silvio Brandani
There was a table set statistics changing the default value, now I remove and run analyze the stats are update correctly but the problem of different plan still stand. I set enable_nestloop off and the query plan is the following, the query is fast now: Hash IN Join (cost=56574.39..11887

Re: [ADMIN] problem on table statistics

2012-01-09 Thread Kevin Grittner
Silvio Brandani wrote: > So there is something wrong with table statistics. It picks the plan which it calculates to have the lowest cost. If the lowest cost doesn't correspond to the fastest plan, the most common cause is that your costing factors need adjustment. > How can I reset the pg_