| From: | Richard Guo <guofenglinux(at)gmail(dot)com> |
|---|---|
| To: | Sergey Shinderuk <s(dot)shinderuk(at)postgrespro(dot)ru> |
| 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 08:18:22 |
| Message-ID: | CAMbWs4-K6eQbRLTZ4XvcTas6E8XirRQtLwBn8AGTrn2c9yGCjw@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Mon, Nov 28, 2022 at 5:59 PM Sergey Shinderuk <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.
> + if (!func_strict(opexpr->opfuncid))
> + return false;
>
> Should return true instead?
Yeah, you're right. This should be a thinko.
Thanks
Richard
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Noah Misch | 2022-12-01 08:25:33 | Re: pgsql: Revoke PUBLIC CREATE from public schema, now owned by pg_databas |
| Previous Message | Masahiko Sawada | 2022-12-01 08:02:57 | Re: [PoC] Improve dead tuple storage for lazy vacuum |