Re: Bug in row_number() optimization - Mailing list pgsql-hackers

From Sergey Shinderuk
Subject Re: Bug in row_number() optimization
Date
Msg-id c039da79-d434-fa21-5de6-f0a0a7257a61@postgrespro.ru
Whole thread Raw
In response to Re: Bug in row_number() optimization  (Richard Guo <guofenglinux@gmail.com>)
Responses Re: Bug in row_number() optimization  (David Rowley <dgrowleyml@gmail.com>)
List pgsql-hackers
On 01.12.2022 11:18, Richard Guo wrote:
> 
> On Mon, Nov 28, 2022 at 5:59 PM Sergey Shinderuk 
> <s.shinderuk@postgrespro.ru <mailto: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.

Maybe I'm missing something, but the previous call to spool_tuples() 
might have read extra tuples (if the tuplestore spilled to disk), and 
after switching to WINDOWAGG_PASSTHROUGH_STRICT mode we nevertheless 
would loop through these extra tuples and call ExecProject if only to 
increment winstate->currentpos.

-- 
Sergey Shinderuk        https://postgrespro.com/




pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: generic plans and "initial" pruning
Next
From: Amit Kapila
Date:
Subject: Re: Perform streaming logical transactions by background workers and parallel apply