Re: [HACKERS] Idea for speeding up uncorrelated subqueries

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us>
Cc: Vadim Mikheev <vadim(at)krs(dot)ru>, pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: [HACKERS] Idea for speeding up uncorrelated subqueries
Date: 1999-08-05 15:13:59
Message-ID: 4444.933866039@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us> writes:
> Yes, the subqueries need work. We don't even do index lookups into the
> inner plan, only sequential. Already on TODO.

Huh? I don't follow that at all...

> The multiple query executions are not on the TODO list. Not sure why
> this is happening here.

After looking at subselect.c I think I understand why --- InitPlans are
only for subqueries that are known to return a *single* reslt. When you
have a subquery that might potentially return many, many tuples, you
need to scan through those tuples, so we use SubPlan tactics even if
there's not a query correlation.

But this neglects the cost of re-executing the subplan over and over.
Materializing the result should help, no? (Of course there are cases
where it won't, such as when the subplan is just an unqualified select,
but most of the time it should be a win, I think...)

regards, tom lane

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Ewan Mellor 1999-08-05 15:16:58 Re: [INTERFACES] Re: [HACKERS] Threads
Previous Message Bruce Momjian 1999-08-05 15:07:28 Re: [HACKERS] Idea for speeding up uncorrelated subqueries