Re: LATERAL quals revisited

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Antonin Houska <antonin(dot)houska(at)gmail(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: LATERAL quals revisited
Date: 2013-08-14 20:04:51
Message-ID: 13860.1376510691@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Antonin Houska <antonin(dot)houska(at)gmail(dot)com> writes:
> On 07/04/2013 06:11 PM, Antonin Houska wrote:
>> On 07/03/2013 08:32 PM, Tom Lane wrote:
>>> Another possibility would be to keep the optimization, but disable it in
>>> queries that use LATERAL. I don't much care for that though --- seems
>>> too Rube Goldbergish, and in any case I have a lot less faith in the
>>> whole concept now than I had before I started digging into this issue.

> I constructed a query that triggers the optimization - see attachment
> with comments.

Thanks for poking at this.

> EXPLAIN shows the same plan with or without the ph_may_need
> optimization, but that might be data problem (my tables are empty).

Yeah, I didn't have much luck getting a different plan even with data in
the tables. What you'd need for this to be important would be for a join
order that's precluded without the ph_may_need logic to be significantly
better than the join orders that are still allowed. While that's
certainly within the realm of possibility, the difficulty of triggering
the case at all reinforces my feeling that this optimization isn't worth
bothering with. For the moment I'm just going to take it out.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Sergey Konoplev 2013-08-14 20:06:58 Re: System catalog vacuum issues
Previous Message Tom Lane 2013-08-14 19:38:35 Re: insert throw error when year field len > 4 for timestamptz datatype