> We could remove the hard limit on statistics target and
> impose the limit
> instead on the actual size of the arrays. Ie, allow people to
> specify larger
> sample sizes and discard unreasonably large excess data
> (possibly warning them
> when that happens).
>
> That would remove the screw case the original poster had
> where he needed to
> scan a large portion of the table to see at least one of
> every value even
> though there were only 169 distinct values.
>
> --
> Gregory Stark
That was my use case, but I wasn't the OP.
Your suggestion would satisfy what I was trying to do. However, a higher stats
target wouldn't solve my root problem (how the planner uses the gathered
stats), and the statistics gathered at 1000 (and indeed at 200) are quite a
good representation of what is in the table.
I don't like the idea of changing one limit into two limits. Or are you
suggesting changing the algorithm that determines how many, and which pages to
analyze, perhaps so that it is adaptive to the results of the analysis as it
progresses? That doesn't sound easy.
Regards,
Stephen Denne.
Disclaimer:
At the Datamail Group we value team commitment, respect, achievement, customer
focus, and courage. This email with any attachments is confidential and may be
subject to legal privilege. If it is not intended for you please advise by
reply immediately, destroy it and do not copy, disclose or use it in any way.
__________________________________________________________________
This email has been scanned by the DMZGlobal Business Quality
Electronic Messaging Suite.
Please see http://www.dmzglobal.com/services/bqem.htm for details.
__________________________________________________________________
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
