| From: | Antonin Houska <antonin(dot)houska(at)gmail(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Kevin Grittner <kgrittn(at)ymail(dot)com> |
| Cc: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Reference to parent query from ANY sublink |
| Date: | 2013-12-13 23:22:44 |
| Message-ID: | 52AB96C4.3030706@gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 12/12/2013 04:36 PM, Tom Lane wrote:
> BTW, on further thought, I'm afraid this is a bigger can of worms than
> it appears. The remarks above presume that the subquery is simple enough
> to be pulled up, which is the case in this example. It might not be too
> hard to make that case work. But what if the subquery *isn't* simple
> enough to be pulled up --- for instance, it includes grouping or
> aggregation? Then there's no way to unify its WHERE clause with the upper
> semijoin qual. At the very least, this breaks the uniqueify-then-do-a-
> plain-join implementation strategy for semijoins.
After having thought about it further, I think I understand.
> So I'm now thinking this patch isn't worth pursuing. Getting all the
> corner cases right would be a significant amount of work, and in the
> end it would only benefit strangely-written queries.
Originally it seemed to me that I just (luckily) found a new opportunity
for the existing infrastructure. To change the infrastructure because of
this small feature would be exactly the opposite. Thanks for having
taken a look at it.
// Antonin Houska (Tony)
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2013-12-14 00:06:50 | Re: INSERT...ON DUPLICATE KEY LOCK FOR UPDATE |
| Previous Message | Christophe Pettus | 2013-12-13 22:58:56 | Re: "stuck spinlock" |