From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Hitoshi Harada <umi(dot)tanuki(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Pull up aggregate subquery |
Date: | 2011-05-24 02:58:54 |
Message-ID: | BANLkTi=Eyoc_aSt4G-gadzF3XMMYoaAxHQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, May 23, 2011 at 4:02 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2011-05-24 03:08:40 | Re: Pull up aggregate subquery |
Previous Message | Robert Haas | 2011-05-24 02:56:05 | Re: patch: Allow \dd to show constraint comments |