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

From Sergey Shinderuk
Subject Re: Bug in row_number() optimization
Date
Msg-id [email protected]
Whole thread Raw
In response to Re: Bug in row_number() optimization  (Richard Guo <[email protected]>)
Responses Re: Bug in row_number() optimization
List pgsql-hackers
On 01.12.2022 11:18, Richard Guo wrote:
> 
> On Mon, Nov 28, 2022 at 5:59 PM Sergey Shinderuk 
> <[email protected] <mailto:[email protected]>> 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