Re: Optimize common expressions in projection evaluation

Поиск
Список
Период
Сортировка
От David G. Johnston
Тема Re: Optimize common expressions in projection evaluation
Дата
Msg-id CAKFQuwYR9K2AVjRp1Eufcg37D9m2rTgu2KPTJPuCzRk=U4WW6Q@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Optimize common expressions in projection evaluation  (Pavel Stehule <pavel.stehule@gmail.com>)
Ответы Re: Optimize common expressions in projection evaluation  (Peifeng Qiu <pgsql@qiupf.dev>)
Список pgsql-hackers
On Sun, Dec 4, 2022 at 9:37 PM Pavel Stehule <pavel.stehule@gmail.com> wrote:

po 5. 12. 2022 v 5:28 odesílatel Tom Lane <tgl@sss.pgh.pa.us> napsal:
Peifeng Qiu <pgsql@qiupf.dev> writes:
>> the need for this code seems not that great.  But as to the code itself I'm unable to properly judge.

I mention this because trying to reverse-engineer this situation
in execExpr seems seriously ugly and inefficient, even assuming
you can make it non-buggy.  The right solution has to involve never
expanding foo().* into duplicate function calls in the first place,
which is the way it used to be.  Maybe if you dug around in those
twenty-year-old changes you could get some inspiration.

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 phrased that poorly.  I agree that having this problem solved would be beneficial to the project.  But, and this is probably a bit unfair to the OP, if Tom decided to implement LATERAL after years of hearing complaints I doubted this patch was going to be acceptable.  The benefit/cost ratio of fixing this in code just doesn't seem to be high enough to try at this point.  But I'd be happy to be proven wrong.  And I readily admit both a lack of knowledge, and that as time has passed maybe we've improved the foundations enough to implement something here.

Otherwise, we can maybe improve the documentation.  There isn't any way (that the project would accept anyway) to actually warn the user at runtime.  If we go that route we should probably just disallow the syntax outright.

David J.



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Optimize common expressions in projection evaluation
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: [PATCH] Add native windows on arm64 support