On Mon, May 23, 2011 at 4:02 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> ...we'd need to plan the subquery twice, once with a parameterized
>> qual m_id = $1 pushed down, and once without that. We could then
>> compare the cost of a nest-loop with the qual to the cost of a merge
>> or hash join without it. But this seems very expensive. In the
>> particular case you have here, the subquery is simple enough that this
>> probably wouldn't be any big deal, but in general there's no reason
>> why that subquery couldn't be quite complex - or why it couldn't have
>> subqueries of its own that would requite the same treatment
>> recursively.
>
> Yeah. For simple scan/join queries it seems likely that we only care
> about parameterizing indexscans, since the main opportunity for a win is
> to not scan all of a large table. Restricting things that way would
> help reduce the number of extra Paths to carry around. But I'm not sure
> whether the same argument can be made for arbitrary subqueries.
I must be misunderstanding you, because index scans are the thing we
already *do* parameterize; and what else would make any sense?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company