On Mon, Mar 19, 2012 at 6:19 PM, Jeff Davis wrote:
> On Sat, 2012-03-17 at 12:48 +, Simon Riggs wrote:
>> The problems are as I described them
>>
>> (1) no account made for sparsity, and other factors leading to an
>> overestimate of rows (N)
>>
>> (2) inappropriate assumption of the effect of
On Sat, 2012-03-17 at 12:48 +, Simon Riggs wrote:
> The problems are as I described them
>
> (1) no account made for sparsity, and other factors leading to an
> overestimate of rows (N)
>
> (2) inappropriate assumption of the effect of LIMIT m, which causes a
> costly SeqScan to appear better
On Sat, Mar 17, 2012 at 11:33 AM, Greg Stark wrote:
> On Sat, Mar 17, 2012 at 9:34 AM, Simon Riggs wrote:
>> My wish was to register this as both a common and significant bug,
>
> It has definitely come up here before many times.
>
> However at root the problem is part of the general class of not
On Sat, Mar 17, 2012 at 9:34 AM, Simon Riggs wrote:
> My wish was to register this as both a common and significant bug,
It has definitely come up here before many times.
However at root the problem is part of the general class of not
understanding how two different columns are related. Postgres
On Fri, Mar 16, 2012 at 9:11 PM, Tom Lane wrote:
> Simon Riggs writes:
>> 2. We assume that if values do exist that they have rows uniformly
>> distributed across the whole table like rungs on a ladder.
>
> Well, yeah. That's sometimes wrong, but not always. In the absence
> of evidence to the
On Fri, Mar 16, 2012 at 9:39 PM, Jeff Davis wrote:
> On Fri, 2012-03-16 at 18:25 +, Simon Riggs wrote:
>> Any time we apply a LIMIT clause to a plan with a SeqScan or
>> unqualified IndexScan, we shouldn't assume the scan will do less than
>> say 10% of the table. It might, but its an unsafe a
On Fri, 2012-03-16 at 18:25 +, Simon Riggs wrote:
> Any time we apply a LIMIT clause to a plan with a SeqScan or
> unqualified IndexScan, we shouldn't assume the scan will do less than
> say 10% of the table. It might, but its an unsafe assumption because
> as the selectivity decreases so does
Simon Riggs writes:
> 2. We assume that if values do exist that they have rows uniformly
> distributed across the whole table like rungs on a ladder.
Well, yeah. That's sometimes wrong, but not always. In the absence
of evidence to the contrary, I think it's a better assumption than
most others
I have a query where the LIMIT clause is incorrectly reducing the cost
of the query. This results in queries doing LIMIT m run much longer
when m is small (e.g. 1-3) than if m is larger. (PG 9.0) (And yes,
ANALYZE was run and, no, increasing stats_target for the columns
doesn't help).
Notice that
