The fact that the estimator knows that the LIMIT is pointless because
there
are less rows in the subselect than the LIMIT will return is not
something we
want to count on; sometimes the estimator has innaccurate information.
The
UNIQUE index makes this more certain, except that I'm not sure
Josh Berkus <[EMAIL PROTECTED]> writes:
> The fact that the estimator knows that the LIMIT is pointless because there
> are less rows in the subselect than the LIMIT will return is not something we
> want to count on; sometimes the estimator has innaccurate information.
However, when the estimato
On Fri, 10 Dec 2004 21:40:18 -0800, Josh Berkus <[EMAIL PROTECTED]> wrote:
> Mike,
> The fact that the estimator knows that the LIMIT is pointless because there
> are less rows in the subselect than the LIMIT will return is not something we
> want to count on; sometimes the estimator has innaccurat
Mike,
> I'm using the fact that Postgres can elevate a subselect-join to a
> simple join when there are no aggregates involved and I think I
> remember there has been some work recently on elevating subselects
> that contain a LIMIT, so I went back and ran the plans without the
> LIMITs to see wha
First off, WOO-HOO! The lists are back and I can finally get my PG
fix!!! Now, on to the business at hand...
I have four query plans below, the first two help explain my question,
and the last two are about a speculative alternative. The first query
use a subselects that are generated from a mi
