From: Tom Lane <tgl@sss.pgh.pa.us>
To: Gregory S. Williamson <gsw@globexplorer.com>
Cc: Plugge, Joe R. <JRPlugge@west.com>
Cc: pgsql-performance@postgresql.org
Subject: Re: Horribly slow query/ sequential scan
Date: Wed, 10 Jan 2007 09:53:42 -0500
Message-ID: <7071.1168440822@sss.pgh.pa.us> (raw)
In-Reply-To: <374.1168408529@sss.pgh.pa.us>
References: <32CC45C5BDC57241B9BCEF37AC0C5DB5021844E6@OMAEXMB02.corp.westworlds.com>
<71E37EF6B7DCC1499CEA0316A256832802B3EB9B@loki.wc.globexplorer.net>
<374.1168408529@sss.pgh.pa.us>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: tgl@sss.pgh.pa.us, gsw@globexplorer.com, JRPlugge@west.com
Subject: Re: Horribly slow query/ sequential scan
In-Reply-To: <7071.1168440822@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox