DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=ymail.com;
	h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding;
	b=WtnFmKBhZ9gl4D4thumwsjL3t7Zr9mjbj20tijUmoij5tsVdBk70ZvPhS70Nbdcph4XrKXFS5olPgvGkZpuu3raBmWvRUIU0uFP7eRqPnrh9qHwkXuXOmCAWhQ1ycGYr6mnZigQo+wZ+yd3mJKPghslMSkcQl4YYw3+ZNyoK/hA=;
References: <1368457293547-5755256.post@n5.nabble.com>
	<CABRT9RBwmDxjq-tzLMh6rFX-suJYVQMiGSQAADsueg07rvB1dg@mail.gmail.com>
	<51916C59.6010700@catalyst.net.nz>
	<1368891351220-5756093.post@n5.nabble.com>
Message-ID: <1369059140.15629.YahooMailNeo@web162906.mail.bf1.yahoo.com>
Date: Mon, 20 May 2013 07:12:20 -0700 (PDT)
From: Kevin Grittner <kgrittn@ymail.com>
Reply-To: Kevin Grittner <kgrittn@ymail.com>
Subject: Re: statistics target for columns in unique constraint?
To: ach <alanchines@gmail.com>,
	"pgsql-performance@postgresql.org" <pgsql-performance@postgresql.org>
In-Reply-To: <1368891351220-5756093.post@n5.nabble.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Precedence: bulk
Sender: pgsql-performance-owner@postgresql.org

ach <alanchines@gmail.com> wrote:

> One quick follow up since I'm expecting y'all might know:=A0 Do the
> statistics targets actually speed performance on an index search
> itself; the actual lookup?=A0 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.=A0 Once a plan is chosen, its execution time is not influenced
by the statistics.=A0 A higher statistics target can increase
planning time.=A0 In a complex query with many joins and many indexes
on the referenced tables, the increase in planning time can be
significant.=A0 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.=A0 If there was a single setting which could
not be materially improved upon for some cases, we wouldn't expose
a configuration option.=A0 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.

--=20
Kevin Grittner
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


--=20
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance