Re: Special-case executor expression steps for common combinations

Поиск
Список
Период
Сортировка
Искать
От
Daniel Gustafsson
Тема
Re: Special-case executor expression steps for common combinations
Дата
Msg-id
A48C4DBC-C6BF-4850-B9CB-D0AC27FB8C3B@yesql.se
Ответ на
Список
Дерево обсуждения
Special-case executor expression steps for common combinations Daniel Gustafsson <daniel@yesql.se>
Re: Special-case executor expression steps for common combinations Heikki Linnakangas <hlinnaka@iki.fi>
Re: Special-case executor expression steps for common combinations Andres Freund <andres@anarazel.de>
Re: Special-case executor expression steps for common combinations Daniel Gustafsson <daniel@yesql.se>
Re: Special-case executor expression steps for common combinations Andreas Karlsson <andreas@proxel.se>
Re: Special-case executor expression steps for common combinations Andreas Karlsson <andreas@proxel.se>
Re: Special-case executor expression steps for common combinations Daniel Gustafsson <daniel@yesql.se>
Re: Special-case executor expression steps for common combinations Andreas Karlsson <andreas@proxel.se>
Re: Special-case executor expression steps for common combinations Andreas Karlsson <andreas@proxel.se>
Re: Special-case executor expression steps for common combinations David Rowley <dgrowleyml@gmail.com>
> On 20 Jun 2024, at 17:22, Andreas Karlsson  wrote:
> 
> On 10/12/23 11:48 AM, Daniel Gustafsson wrote:
>> Thoughts?
> 
> I have looked at the patch and it still applies, builds and passes the test cases and I personally think these optimizations are pretty much no-brainers that we should do and it is a pity nobody has had the time to review this patch.
> 
> 1) The no-return case should help with the JIT, making jitted code faster.
> 
> 2) The specialized strict steps helps with many common queries in the interpreted mode.
> 
> The code itself looks really good (great work!) but I have two comments on it.

Thanks for review!

> 1) I think the patch should be split into two. The two different optimizations are not related at all other than that they create specialized versions of expressions steps. Having them as separate makes the commit history easier to read for future developers.

That's a good point, the attached v2 splits it into two separate commits.

> 2) We could generate functions which return void rather than NULL and therefore not have to do a return at all but I am not sure that small optimization and extra clarity would be worth the hassle. The current approach with adding Assert() is ok with me. Daniel, what do you think?

I'm not sure that would move the needle enough to warrant the extra complexity.
It could be worth pursuing, but it can be done separately from this.

--
Daniel Gustafsson

В списке pgsql-hackers по дате отправления
От: Tom Lane
Дата:
От: jian he
Дата:
Сообщение: refactor the CopyOneRowTo
FAQ