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: | Raw Message | Whole Thread | 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" |