Re: A little cosmetic to convert_VALUES_to_ANY()
От | David Rowley |
---|---|
Тема | Re: A little cosmetic to convert_VALUES_to_ANY() |
Дата | |
Msg-id | CAApHDvphU6T68p8JyM7pmpvTjfteUf5B2n_xPvG-dBEdUGcPbA@mail.gmail.com обсуждение исходный текст |
Ответ на | A little cosmetic to convert_VALUES_to_ANY() (Tender Wang <tndrwang@gmail.com>) |
Список | pgsql-hackers |
On Sun, 27 Jul 2025 at 19:53, Tender Wang <tndrwang@gmail.com> wrote: > While debugging the pull-up sublink codes, I noticed the convert_VALUES_to_ANY(). > The function is to convert "where colX in VALUES(xxx)" into SAOP. It firstly scans the values_list to > make sure no volatile function is in this list, then it scans this values_list again to check that it > only includes Const items. > > We can merge the two scans into one. This can reduce the time complexity from 2O(n) to O(n). I imagine that >95% of the time, probably more, the VALUES list is going to contain only Consts, and if anything is done here, then it likely should be to skip the convert_testexpr() / eval_const_expressions() rigmarole when the input is already Const. The proposal to move the contain_volatile_functions() doesn't seem like a good idea to me as technically putting it where you propose makes it mostly redundant (eval_const_expressions() will never evaluate a volatile function and return a Const). I suspect it's there because it's a slightly cheaper pre-check, and if you move it to inside the loop then you may end up doing a bunch of work in eval_const_expressions(), such as function inlining, which will just be thrown away if you discover that the next item in the VALUES list has a volatile. Might be worth checking the planning overheads of large VALUES list and seeing if it's worth putting the call to convert_testexpr() and eval_const_expressions() inside an if (!IsA(value, Const)). David
В списке pgsql-hackers по дате отправления: