On Mon, May 23, 2011 at 4:02 PM, Tom Lane <t...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
