Re: Reference to parent query from ANY sublink

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)

In response to

Browse pgsql-hackers by date

  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"