To: Michael Stone <mstone+postgres@mathom.us>
cc: pgsql-performance@postgresql.org
Subject: Re: TB-sized databases 
In-reply-to: <20071206154212.GP5294@mathom.us> 
References: <4544e0330711260904g45d893a8ub1731e245aa8fc84@mail.gmail.com>
	<13851.1196351131@sss.pgh.pa.us>
	<1196352866.4246.1304.camel@ebony.site>
	<200712051507.22745.xzilla@users.sourceforge.net>
	<1196933896.4255.340.camel@ebony.site>
	<20071206154212.GP5294@mathom.us>
Comments: In-reply-to Michael Stone <mstone+postgres@mathom.us>
	message dated "Thu, 06 Dec 2007 10:42:14 -0500"
Date: Thu, 06 Dec 2007 11:13:18 -0500
Message-ID: <15753.1196957598@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Michael Stone <mstone+postgres@mathom.us> writes:
> OTOH, the planner can really screw up queries on really large databases. 
> IIRC, the planner can use things like unique constraints to get some 
> idea, e.g., of how many rows will result from a join. Unfortunately, 
> the planner can't apply those techniques to certain constructs common in 
> really large db's (e.g., partitioned tables--how do you do a unique 
> constraint on a partitioned table?) I've got some queries that the 
> planner thinks will return on the order of 10^30 rows for that sort of 
> reason. In practice, the query may return 10^3 rows, and the difference 
> between the seq scan and the index scan is the difference between a 
> query that takes a few seconds and a query that I will never run to 
> completion. I know the goal would be to make the planner understand 
> those queries better,

Indeed, and if you've got examples where it's that far off, you should
report them.

			regards, tom lane