Re: performance of IN (subquery) - Mailing list pgsql-general

From Paul Tillotson
Subject Re: performance of IN (subquery)
Date
Msg-id 412F4022.4090607@shentel.net
Whole thread Raw
In response to performance of IN (subquery)  (Kevin Murphy <murphy@genome.chop.edu>)
Responses Re: performance of IN (subquery)  ("Matthew T. O'Connor" <matthew@zeut.net>)
List pgsql-general
>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

pgsql-general by date:

Previous
From: Santiago Cassina
Date:
Subject: Audit
Next
From: Tom Lane
Date:
Subject: Re: performance of IN (subquery)