Re: Optimize common expressions in projection evaluation

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Optimize common expressions in projection evaluation
Дата
Msg-id 3101062.1670214477@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Optimize common expressions in projection evaluation  (Peifeng Qiu <pgsql@qiupf.dev>)
Ответы Re: Optimize common expressions in projection evaluation  (Pavel Stehule <pavel.stehule@gmail.com>)
Список pgsql-hackers
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.

> A simplified version of my use case is like this:
> CREATE FOREIGN TABLE ft(rawdata json);
> INSERT INTO tbl SELECT (convert_func(rawdata)).* FROM ft;

It might be worth noting that the code as we got it from Berkeley
could do this scenario without multiple evaluations of convert_func().
Memory is foggy, but I believe it involved essentially a two-level
targetlist.  Unfortunately, the scheme was impossibly baroque and
buggy, so we eventually ripped it out altogether in favor of the
multiple-evaluation behavior you see today.  I think that commit
62e29fe2e might have been what ripped it out, but I'm not quite
sure.  It's about the right time-frame, anyway.

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.

            regards, tom lane



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

Предыдущее
От: David Rowley
Дата:
Сообщение: Re: Bug in row_number() optimization
Следующее
От: "houzj.fnst@fujitsu.com"
Дата:
Сообщение: RE: Perform streaming logical transactions by background workers and parallel apply