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  (Sergey Shinderuk <s.shinderuk@postgrespro.ru>)
Re: Bug in row_number() optimization  (David Rowley <dgrowleyml@gmail.com>)
Список 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.
 
+   if (!func_strict(opexpr->opfuncid))
+       return false;

Should return true instead?
 
Yeah, you're right.  This should be a thinko.

Thanks
Richard

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

Предыдущее
От: Masahiko Sawada
Дата:
Сообщение: Re: [PoC] Improve dead tuple storage for lazy vacuum
Следующее
От: Noah Misch
Дата:
Сообщение: Re: pgsql: Revoke PUBLIC CREATE from public schema, now owned by pg_databas