"Nick Fankhauser" <[EMAIL PROTECTED]> writes:
> The "Before" database:
> attname | attdispersion | starelid | staattnum | staop |
> stanullfrac | stacommonfrac | stacommonval | staloval |
> stahival
> --------------------------+---------------+----------+-----------+-------+--
> -----------+---------------+---------------+-----------------------------+--
> ---------------------
> actor_id | 0.00761992 | 2591915 | 1 | 1066 |
> 0 | 0.0335872 | JTW | 18105A08315 49 | XS
> The "After" database:
> attname | attdispersion | starelid | staattnum | staop |
> stanullfrac | stacommonfrac | stacommonval | staloval
> | stahival
> --------------------------+---------------+----------+-----------+-------+--
> -----------+---------------+--------------------+---------------------------
> -+-----------------------
> actor_id | 0.03247 | 33979335 | 1 | 1066 |
> 0 | 0.112092 | 18105XS | 18105A |
> 18105XS
Hm. In the "before" case you are showing JTW as the most common
actor_id, with a frequency of 3.36% of the entries (busy judge,
I suppose).
In the "after" case you are showing "18105XS" as the most common
actor_id, with a frequency of 11.2% of the entries. Where'd that
come from? Is it correct?
The change in plans occurs because of the increase in stacommonfrac.
7.1 basically uses stacommonfrac as the selectivity estimate if the
constant is the stacommonval, otherwise stacommonfrac/10. So if
stacommonfrac goes up, so does the estimated number of rows retrieved,
and that's what's changing your plan.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
