(2014/06/13 1:37), Tom Lane wrote:
> I wrote:
>> We have a couple votes for this patch and no one has spoken against it,
>> so I'll go ahead and push it into HEAD.
>
> BTW, I forgot to mention that while working on this patch I was thinking
> it's past time to separate out the subquery support in
I wrote:
> We have a couple votes for this patch and no one has spoken against it,
> so I'll go ahead and push it into HEAD.
BTW, I forgot to mention that while working on this patch I was thinking
it's past time to separate out the subquery support in allpaths.c into
its own file. With this patc
Robert Haas writes:
> On Thu, Jun 5, 2014 at 10:27 PM, Tom Lane wrote:
>> The attached draft patch fixes this by deleting unused output expressions
>> from unflattened subqueries, so that we get:
>> ...
>> I'm not entirely convinced that it's worth the extra planning cycles,
>> though. Given the
On Thu, Jun 5, 2014 at 10:27 PM, Tom Lane wrote:
> The attached draft patch fixes this by deleting unused output expressions
> from unflattened subqueries, so that we get:
>
> regression=# explain select f1 from (select * from t1 left join t2 on f1=f2
> limit 1) ss;
>
On Fri, Jun 6, 2014 at 2:27 PM, Tom Lane wrote:
> I'm not entirely convinced that it's worth the extra planning cycles,
> though. Given the small number of complaints to date, it might not
> be worth doing this. Thoughts?
>
>
That's a difficult question for sure. Obviously it's going to depend
On 6/5/14, 9:54 PM, Tom Lane wrote:
Rod Taylor writes:
On Thu, Jun 5, 2014 at 10:27 PM, Tom Lane wrote:
I'm not entirely convinced that it's worth the extra planning cycles,
though. Given the small number of complaints to date, it might not
be worth doing this. Thoughts?
Would this avoid
Rod Taylor writes:
> On Thu, Jun 5, 2014 at 10:27 PM, Tom Lane wrote:
>> I'm not entirely convinced that it's worth the extra planning cycles,
>> though. Given the small number of complaints to date, it might not
>> be worth doing this. Thoughts?
> Would this avoid execution of expensive funct
On Thu, Jun 5, 2014 at 10:27 PM, Tom Lane wrote:
> I'm not entirely convinced that it's worth the extra planning cycles,
> though. Given the small number of complaints to date, it might not
> be worth doing this. Thoughts?
>
Would this avoid execution of expensive functions in views when thei
A question in pgsql-general made me reflect about how the planner isn't
smart about unreferenced output columns of subqueries that it's not able
to flatten into the parent query. Here's an example:
regression=# create table t1 (f1 int);
CREATE TABLE
regression=# create table t2 (f2 int primary ke
