From: | Greg Stark <gsstark(at)mit(dot)edu> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: DELETE syntax on JOINS |
Date: | 2009-08-25 14:08:10 |
Message-ID: | 407d949e0908250708l6097c98tcf67481eb306ea7e@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Aug 25, 2009 at 2:50 PM, Tom Lane<tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> On the performance front: yeah, you can recast most joins as subqueries,
> but you tend to end up with the equivalent of a nestloop plan. Works
> okay for small numbers of rows, scales horribly.
Well that's our problem isn't it? I thought we were capable of
genearting semijoins for subqueries these days though?
The problem I thought was if you wanted to pull multiple values out of
the subquery.
So something like
UPDATE foo set a=aa, b=bb FROM bar WHERE ...
If you wanted to do an outer join from foo to bar then how would you
write it as an subquery even if our optimizer could notice the
semijoin and optimize it properly?
You would have to write something like
UPDATE foo set a = (select aa from bar where...)
b = (select bb from bar where...)
and then the optimizer would have to notice the duplicates and
consolidate them? That seems inconvenient (and fragile).
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2009-08-25 14:19:56 | Re: DELETE syntax on JOINS |
Previous Message | Andrew Dunstan | 2009-08-25 13:57:38 | Re: DELETE syntax on JOINS |