Re: Optimize common expressions in projection evaluation

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
Cc: Peifeng Qiu <pgsql(at)qiupf(dot)dev>, "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Optimize common expressions in projection evaluation
Date: 2022-12-05 04:47:53
Message-ID: 3102800.1670215673@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> writes:
> po 5. 12. 2022 v 5:28 odesílatel Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> napsal:
>> I tend to agree with David that LATERAL offers a good-enough
>> solution in most cases ... but it is annoying that we accept
>> this syntax and then pessimize it.

> I agree, so there is a perfect solution like don't use .*, but on second
> hand any supported syntax should be optimized well or we should raise some
> warning about negative performance impact.

Yeah. I wonder if we could get the parser to automatically transform

SELECT (foo(t.x)).* FROM tab t

into

SELECT f.* FROM tab t, LATERAL foo(t.x) f

There are probably cases where this doesn't work or changes the
semantics subtly, but I suspect it could be made to work in
most cases of practical interest.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message David G. Johnston 2022-12-05 04:53:11 Re: Optimize common expressions in projection evaluation
Previous Message David Rowley 2022-12-05 04:39:37 Re: Bug in row_number() optimization