Re: Bug in row_number() optimization
| От | Richard Guo |
|---|---|
| Тема | Re: Bug in row_number() optimization |
| Дата | |
| Msg-id | CAMbWs4-K6eQbRLTZ4XvcTas6E8XirRQtLwBn8AGTrn2c9yGCjw@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Bug in row_number() optimization (Sergey Shinderuk <s.shinderuk@postgrespro.ru>) |
| Ответы |
Re: Bug in row_number() optimization
Re: Bug in row_number() optimization |
| Список | pgsql-hackers |
On Mon, Nov 28, 2022 at 5:59 PM Sergey Shinderuk <s.shinderuk@postgrespro.ru> wrote:
Not quite sure that we don't need to do anything for the
WINDOWAGG_PASSTHROUGH_STRICT case. Although, we won't return any more
tuples for the current partition, we still call ExecProject with
dangling pointers. Is it okay?
AFAIU once we go into WINDOWAGG_PASSTHROUGH_STRICT we will spool all the
remaining tuples in the current partition without storing them and then
move to the next partition if available and become WINDOWAGG_RUN again
or become WINDOWAGG_DONE if there are no further partitions. It seems
we would not have chance to see the dangling pointers.
remaining tuples in the current partition without storing them and then
move to the next partition if available and become WINDOWAGG_RUN again
or become WINDOWAGG_DONE if there are no further partitions. It seems
we would not have chance to see the dangling pointers.
+ if (!func_strict(opexpr->opfuncid))
+ return false;
Should return true instead?
Yeah, you're right. This should be a thinko.
Thanks
Richard
Thanks
Richard
В списке pgsql-hackers по дате отправления: