Horton

Re: Pull up aggregate subquery

Robert Haas <robertmhaas@gmail.com>

View thread
From: Robert Haas <robertmhaas@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Hitoshi Harada <umi.tanuki@gmail.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2011-05-24T02:58:54Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Make NestLoop plan nodes pass outer-relation variables into their inner

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