Re: Bug in row_number() optimization
От | David Rowley |
---|---|
Тема | Re: Bug in row_number() optimization |
Дата | |
Msg-id | CAApHDvrpPx3gWQahDSUK_=PBdDgbkqOADe2-1btZDfLfDZ-ACQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Bug in row_number() optimization (Sergey Shinderuk <s.shinderuk@postgrespro.ru>) |
Ответы |
Re: Bug in row_number() optimization
|
Список | pgsql-hackers |
On Fri, 25 Nov 2022 at 00:52, Sergey Shinderuk <s.shinderuk@postgrespro.ru> wrote: > Shouldn't we handle any pass-by-reference type the same? I suppose, a > user-defined window function can return some other type, not int8. Thanks for reporting this and to you and Richard for working on a fix. I've just looked at it and it seems that valgrind is complaining because a tuple formed by an upper-level WindowAgg contains a pointer to free'd memory due to the byref type and eval_windowaggregates() not having been executed to fill in ecxt_aggvalues and ecxt_aggnulls on the lower-level WindowAgg. Since upper-level WindowAggs cannot reference values calculated in some lower-level WindowAgg, why can't we just NULLify the pointers instead? See attached. It is possible to have a monotonic window function that does not return int8. Technically something like MAX(text_col) OVER (PARTITION BY somecol ORDER BY text_col) is monotonically increasing, it's just that I didn't add a support function to tell the planner about that. Someone could come along in the future and suggest we do that and show us some convincing use case. So whatever the fix, it cannot assume the window function's return type is int8. David
Вложения
В списке pgsql-hackers по дате отправления: