Re: [HACKERS] Suboptimal plan choice problem with 8.3RC2

2008-01-23 Thread Guillaume Smet
On Jan 22, 2008 11:37 PM, Guillaume Smet <[EMAIL PROTECTED]> wrote: > I can't drop/recreate the database at will because the customer is > also testing it but I'll try to find a moment to do it tomorrow. I didn't reproduce the problem this time. I'll check after each drop/recreate to see if I got

Re: [HACKERS] Suboptimal plan choice problem with 8.3RC2

2008-01-22 Thread Guillaume Smet
On Jan 22, 2008 11:22 PM, Alvaro Herrera <[EMAIL PROTECTED]> wrote: > > So I wonder why the stats were so bad... I didn't update the data at > > all after the initial import. Any idea? > > Hmm, perhaps the analyze was done with the default statistic target (10)? It's set to 30 in the postgresql.co

Re: [HACKERS] Suboptimal plan choice problem with 8.3RC2

2008-01-22 Thread Alvaro Herrera
Guillaume Smet escribió: > It seems that autovacuum took care of them just after the import which > is what I expected: [...] > So I wonder why the stats were so bad... I didn't update the data at > all after the initial import. Any idea? Hmm, perhaps the analyze was done with the default stati

Re: [HACKERS] Suboptimal plan choice problem with 8.3RC2

2008-01-22 Thread Guillaume Smet
On Jan 22, 2008 9:52 PM, Alvaro Herrera <[EMAIL PROTECTED]> wrote: > No, autovacuum should have taken care of it. I would be interesting in > knowing why it didn't. I just dropped the database on monday morning and import it again. Nothing really fancy. It seems that autovacuum took care of them

Re: [HACKERS] Suboptimal plan choice problem with 8.3RC2

2008-01-22 Thread Alvaro Herrera
Guillaume Smet escribió: > On Jan 22, 2008 8:28 PM, Tom Lane <[EMAIL PROTECTED]> wrote: > > I'd expect 8.1 to make about the same estimate given the same stats, > > so I think it's not looking at the same stats. > > Yep, the statistics were the problem, sorry for the noise. The query > performs i

Re: [HACKERS] Suboptimal plan choice problem with 8.3RC2

2008-01-22 Thread Guillaume Smet
On Jan 22, 2008 8:28 PM, Tom Lane <[EMAIL PROTECTED]> wrote: > The only way the merge join could have an estimated cost that's barely > 1% of the estimate for one of its inputs is if the planner thinks the > merge will stop after reading only 1% of that input, ie, the largest > a.numasso value is o

Re: [HACKERS] Suboptimal plan choice problem with 8.3RC2

2008-01-22 Thread Tom Lane
"Guillaume Smet" <[EMAIL PROTECTED]> writes: > While testing RC2 on the new servers of one of our customers, I found > a query really slow on the new server which is quite fast on the old > box currently in production (production is 8.1 at the moment). Have you ANALYZEd these tables lately? It lo