Mime-Version: 1.0 (Apple Message framework v752.3)
In-Reply-To: <115.1180063568@sss.pgh.pa.us>
References: 
 <8C5B026B51B6854CBE88121DBF097A86C3A30D@ehost010-33.exch010.intermedia.net>
	<27828.1180055291@sss.pgh.pa.us>
	<20070525023922.GV4320@alvh.no-ip.org>
	<29662.1180061117@sss.pgh.pa.us>
	<46565086.2040705@commandprompt.com> <115.1180063568@sss.pgh.pa.us>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <23385219-5252-468A-BBC9-69516DA81C2A@blighty.com>
Content-Transfer-Encoding: 7bit
From: Steve Atkins <steve@blighty.com>
Subject: Re: index vs. seq scan choice? 
Date: Thu, 24 May 2007 21:25:23 -0700
To: PostgreSQL General <pgsql-general@postgresql.org>


On May 24, 2007, at 8:26 PM, Tom Lane wrote:

> "Joshua D. Drake" <jd@commandprompt.com> writes:
>> Tom Lane wrote:
>>> I'm not sure I want to vote for another 10x increase by
>>> default, though.
>
>> Outside of longer analyze times, and slightly more space taken up  
>> by the
>> statistics, what is the downside?
>
> Longer plan times --- several of the selfuncs.c routines grovel  
> over all
> the entries in the pg_statistic row.  AFAIK no one's measured the real
> impact of that, but it could easily be counterproductive for simple  
> queries.

The lateness of the hour is suppressing my supposed statistics savvy,
so this may not make sense, but...

Would it be possible to look at a much larger number of samples  
during analyze,
then look at the variation in those to generate a reasonable number of
pg_statistic "samples" to represent our estimate of the actual  
distribution?
More datapoints for tables where the planner might benefit from it,  
fewer
where it wouldn't.

Cheers,
   Steve