Re: Bug in row_number() optimization

From: Sergey Shinderuk <s(dot)shinderuk(at)postgrespro(dot)ru>
To: Richard Guo <guofenglinux(at)gmail(dot)com>
Cc: David Rowley <dgrowleyml(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, David Rowley <drowley(at)postgresql(dot)org>
Subject: Re: Bug in row_number() optimization
Date: 2022-12-01 11:21:47
Message-ID: c039da79-d434-fa21-5de6-f0a0a7257a61@postgrespro.ru
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 01.12.2022 11:18, Richard Guo wrote:
>
> On Mon, Nov 28, 2022 at 5:59 PM Sergey Shinderuk
> <s(dot)shinderuk(at)postgrespro(dot)ru <mailto:s(dot)shinderuk(at)postgrespro(dot)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/

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2022-12-01 12:39:54 Re: Perform streaming logical transactions by background workers and parallel apply
Previous Message Alvaro Herrera 2022-12-01 11:21:06 Re: generic plans and "initial" pruning