Skip site navigation (1) Skip section navigation (2)

Re: limit clause breaks query planner?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Guillaume Cottenceau <gc(at)mnc(dot)ch>
Cc: Matthew Wakeling <matthew(at)flymine(dot)org>, pgsql-performance(at)postgresql(dot)org
Subject: Re: limit clause breaks query planner?
Date: 2008-09-04 17:14:32
Message-ID: 25328.1220548472@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-performance
Guillaume Cottenceau <gc(at)mnc(dot)ch> writes:
> It seems to me that if the correlation is 0.99[1], and you're
> looking for less than 1% of rows, the expected rows may be at the
> beginning or at the end of the heap?

Right, but if you know the value being searched for, you could then
estimate where it is in the table by consulting the histogram.

Actually, an even easier hack (which would have the nice property of not
needing to know the exact value being searched for), would simply use
the existing cost estimates if the WHERE variables have low correlation
(meaning the random-locations assumption is probably good), but apply
some sort of penalty factor if the correlation is high.  This would
amount to assuming that the universe is perverse and high correlation
will always mean that the rows we want are at the wrong end of the table
not the right one.  But any DBA will tell you that the universe is
indeed perverse ;-)

OTOH, since indexscans get a cost estimate reduction in the presence of
high correlation, we're already biasing the choice in the direction of
indexscans for high correlation.  We may not need to do it twice.
I don't recall whether the OP ever showed us his statistics for the
table in question --- did it even appear to have high correlation?

			regards, tom lane

In response to

Responses

pgsql-performance by date

Next:From: Scott CareyDate: 2008-09-04 18:04:29
Subject: Re: limit clause breaks query planner?
Previous:From: Matthew WakelingDate: 2008-09-04 16:20:12
Subject: Re: limit clause breaks query planner?

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group