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

Peripheral Links

Header And Logo

PostgreSQL
| The world's most advanced open source database.

Site Navigation

Search for
  Advanced Search

Re: "explain analyse" much slower than actual query


  • From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
  • To: "Phil Endecott" <spam_from_postgresql_general(at)chezphil(dot)org>
  • Cc: pgsql-general(at)postgresql(dot)org
  • Subject: Re: "explain analyse" much slower than actual query
  • Date: Sun, 28 Jan 2007 16:28:15 -0500
  • Message-id: <22445(dot)1170019695(at)sss(dot)pgh(dot)pa(dot)us>

"Phil Endecott" <spam_from_postgresql_general(at)chezphil(dot)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



Home | Main Index | Thread Index

Privacy Policy | PostgreSQL Archives hosted by Command Prompt, Inc. | Designed by tinysofa
Copyright © 1996 – 2008 PostgreSQL Global Development Group