Re: "explain analyse" much slower than actual query - Mailing list pgsql-general

From Tom Lane
Subject Re: "explain analyse" much slower than actual query
Date
Msg-id 22445.1170019695@sss.pgh.pa.us
Whole thread Raw
In response to Re: "explain analyse" much slower than actual query  ("Phil Endecott" <spam_from_postgresql_general@chezphil.org>)
List pgsql-general
"Phil Endecott" <spam_from_postgresql_general@chezphil.org> writes:
> If I understand it correctly, it is still doing a sequential scan on
> part_tsearch that does not terminate early due to the limit clause.  So
> I'm still seeing run times that are rather worse than I think should be
> possible.  Can it not step through the indexes in the way that it does
> for a Merge Join until it has got enough results to satisfy the limit,
> and then terminate?

Nope, there is not that much intelligence about NOT IN.

You could possibly manually rewrite the thing as a LEFT JOIN
with a WHERE inner-join-key IS NULL clause.  This would probably
lose if most of the outer relation's rows join to many inner rows,
though.

            regards, tom lane

pgsql-general by date:

Previous
From: garry saddington
Date:
Subject: Re: counting query
Next
From: "Merlin Moncure"
Date:
Subject: Re: PostgreSQL data loss