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

Re: Horribly slow query/ sequential scan

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Gregory S(dot) Williamson" <gsw(at)globexplorer(dot)com>
Cc: "Plugge, Joe R(dot)" <JRPlugge(at)west(dot)com>, pgsql-performance(at)postgresql(dot)org
Subject: Re: Horribly slow query/ sequential scan
Date: 2007-01-10 14:53:42
Message-ID: 7071.1168440822@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-performance
I wrote:
> ... What seems to be happening is that Informix is willing to
> flatten the sub-SELECT into an IN join even though the sub-SELECT is
> correlated to the outer query (that is, it contains outer references).

I did some googling this morning and found confirmation that recent
versions of Informix have pretty extensive support for optimizing
correlated subqueries:
http://www.iiug.org/waiug/archive/iugnew83/FeaturesIDS73.htm

This is something we've not really spent much time on for Postgres,
but it might be interesting to look at someday.  Given that the problem
with your query was really a mistake anyway, I'm not sure that your
example is compelling evidence for making it a high priority.

			regards, tom lane

In response to

pgsql-performance by date

Next:From: Jeremy HaileDate: 2007-01-10 16:17:22
Subject: Slow inner join, but left join is fast
Previous:From: Florian WeimerDate: 2007-01-10 09:33:53
Subject: Re: High inserts, bulk deletes - autovacuum vs scheduled vacuum

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