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
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 |