Re: performance of IN (subquery)

>2. Instability of plans.  Right now, the planner will not change plans
>   underneath you --- you have to issue an explicit VACUUM or ANALYZE
>   to change the terms of discussion.  That would stop being true if
>   physical file size were always taken into account.  Maybe this is a
>   problem, or maybe it isn't ... as someone who likes to be able to
>   debug planner behavior without actually creating umpteen-gig test
>   tables, my world view may be a bit skewed ...
>
>It's certainly doable if we decide the pluses outweigh the minuses.
>Thoughts?
>
>
>
Even though Ijust proposed it, now I think that the idea of having
postgres automatically gather statistics only when an estimate is
grossly wrong is not a good one. This will just obscure the need to run
analyze, and many people will then always be using moderately bad
statistics without realizing it.

(I think I used postgres in a production environment for about six
months without even knowing about the ANALYZE command--with small data
sets it's not obvious--and it was still blazingly fast compared to foxpro.)

If pgautovacuum does ANALYZE and we can get most people to use
pgautovacuum, I think this problem will go away.

Another possibility is simply to make postgres generate a warning, saying:

WARNING: statistics for table xxxxxx are off by a factor of y. You
should ANALYZE this table.

Paul