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: (view raw, whole thread or download thread mbox)
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:

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-2017 The PostgreSQL Global Development Group