From: | Kevin Grittner <kgrittn(at)ymail(dot)com> |
---|---|
To: | ach <alanchines(at)gmail(dot)com>, "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: statistics target for columns in unique constraint? |
Date: | 2013-05-20 14:12:20 |
Message-ID: | 1369059140.15629.YahooMailNeo@web162906.mail.bf1.yahoo.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
ach <alanchines(at)gmail(dot)com> wrote:
> One quick follow up since I'm expecting y'all might know: Do the
> statistics targets actually speed performance on an index search
> itself; the actual lookup? Or are the JUST to inform the planner
> towards the best pathway decision?
Since the statistics are just a random sampling and generally not
completely up-to-date, they really can't be used for anything other
than *estimating* relative costs in order to try to pick the best
plan. Once a plan is chosen, its execution time is not influenced
by the statistics. A higher statistics target can increase
planning time. In a complex query with many joins and many indexes
on the referenced tables, the increase in planning time can be
significant. I have seen cases where blindly increasing the
default statistics target resulted in planning time which was
longer than run time -- without any increase in plan quality.
Generally when something is configurable, it's because there can be
benefit to adjusting it. If there was a single setting which could
not be materially improved upon for some cases, we wouldn't expose
a configuration option. This is something which is not only
globally adjustable, you can override the setting for individual
columns -- again, we don't go to the trouble of supporting that
without a good reason.
--
Kevin Grittner
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Tomas Vondra | 2013-05-20 20:57:13 | Re: Reliability with RAID 10 SSD and Streaming Replication |
Previous Message | Scott Marlowe | 2013-05-20 03:57:32 | Re: Hardware suggestions for maximum read performance |