Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rpPoT-006bPi-5B for pgsql-hackers@arkaria.postgresql.org; Wed, 27 Mar 2024 09:43:18 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1rpPoS-00Ce28-6B for pgsql-hackers@arkaria.postgresql.org; Wed, 27 Mar 2024 09:43:16 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rpPGO-00CJTQ-E9 for pgsql-hackers@lists.postgresql.org; Wed, 27 Mar 2024 09:08:04 +0000 Received: from sender4-op-o11.zoho.com ([136.143.188.11]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rpPGH-006jYM-Ag for pgsql-hackers@postgresql.org; Wed, 27 Mar 2024 09:08:02 +0000 ARC-Seal: i=1; a=rsa-sha256; t=1711530468; cv=none; d=zohomail.com; s=zohoarc; b=WfyfzJ/Evj7NB5N1UabJk5dbcclgIokR7tjBWTvFDGCnxt9ccUkhLBE0RkM+vCaDpybwd0Z+wNu94aX8jUMbzqiFA10SAYgt03vZc9dcxfemCO1VqOPcBCy+Gq0F8M0XKiMO7pAIN9SG4/0rLVQkJDQatmRVgXse7F7uljo5Er0= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1711530468; h=Content-Type:Date:Date:From:From:MIME-Version:Message-ID:Subject:Subject:To:To:Message-Id:Reply-To:Cc; bh=KgItWdsKt4LO6UvQRoEAdmHgX3OoeY4i2hUBCcyvMuk=; b=bv3oQJzJdYoxOpzshUVi8ivxaKrA+XlZ7f+zSmVAYPWNZ2G5rw94AGjBBvLQuGe1yzNPfxOvsA91McadeUSkTdpZhvIWtH7dueAzHwR3EqFrxxPnOWXFAb2L1DcNwuS3gm9mqBSTi0DT6eY0xj3miuQJHnXwj0rMHx9go2e/5ao= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass header.i=zohocorp.com; spf=pass smtp.mailfrom=vallimaharajan.gs@zohocorp.com; dmarc=pass header.from= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1711530468; s=admin; d=zohocorp.com; i=vallimaharajan.gs@zohocorp.com; h=Date:Date:From:From:To:To:Message-Id:Message-Id:In-Reply-To:Subject:Subject:MIME-Version:Content-Type:Reply-To:Cc; bh=KgItWdsKt4LO6UvQRoEAdmHgX3OoeY4i2hUBCcyvMuk=; b=Fa+UsTq0GxIlxiYLjOS98QwrCMlPMRejLtya2TXxqMXkcJvD4+jEtJK4yIiZno7j EoGcrdF2o7dEdwx+2HhznZ8KAyz5TpKQxBvX42DRWVT97ZDCpSwgvtsu6JCuMAsqN01 +WMQOfR1cWeYmTEj1GsMkOr/5oe6Ql5IwhyXHYiY= Received: from mail.zoho.com by mx.zohomail.com with SMTP id 1711530464477447.98048416613995; Wed, 27 Mar 2024 02:07:44 -0700 (PDT) Date: Wed, 27 Mar 2024 14:37:43 +0530 From: Vallimaharajan G To: "pgsql-hackers" Message-Id: <18e7f2a5167.fe36253866818.977923893562469143@zohocorp.com> In-Reply-To: Subject: Query Regarding frame options initialization in Window aggregate state MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_236021_530436847.1711530463593" Importance: Medium User-Agent: Zoho Mail X-Mailer: Zoho Mail List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk ------=_Part_236021_530436847.1711530463593 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Team, =C2=A0 =C2=A0 =C2=A0I am currently referring to the Postgres source code (p= sql (PostgreSQL) 14.3) and came across a particular section related to wind= ow aggregate initialization that has left me with a question. Specifically,= I noticed a conditional case in the initialization of per aggregate (initi= alize_peraggregate in nodeWindowAgg.c) where the winstate frameOptions is b= eing checked, but it appears that frameOptions is not set before this condi= tional case. I observed the same behaviour in PG version 16 as well. /* * Figure out whether we want to use the moving-aggregate implementation, * and collect the right set of fields from the pg_attribute entry. * * It's possible that an aggregate would supply a safe moving-aggregate * implementation and an unsafe normal one, in which case our hand is * forced. Otherwise, if the frame head can't move, we don't need * moving-aggregate code. Even if we'd like to use it, don't do so if the * aggregate's arguments (and FILTER clause if any) contain any calls to * volatile functions. Otherwise, the difference between restarting and * not restarting the aggregation would be user-visible. */ if (!OidIsValid(aggform->aggminvtransfn)) use_ma_code =3D false; /* sine qua non */ else if (aggform->aggmfinalmodify =3D=3D AGGMODIFY_READ_ONLY && aggform->aggfinalmodify !=3D AGGMODIFY_READ_ONLY) use_ma_code =3D true; /* decision forced by safety */ else if (winstate->frameOptions & FRAMEOPTION_START_UNBOUNDED_PRECEDING) use_ma_code =3D false; /* non-moving frame head */ else if (contain_volatile_functions((Node *) wfunc)) use_ma_code =3D false; /* avoid possible behavioral change */ else use_ma_code =3D true; /* yes, let's use it */ if (use_ma_code) { peraggstate->transfn_oid =3D transfn_oid =3D aggform->aggmtransfn; peraggstate->invtransfn_oid =3D invtransfn_oid =3D aggform->aggminvtransfn; peraggstate->finalfn_oid =3D finalfn_oid =3D aggform->aggmfinalfn; finalextra =3D aggform->aggmfinalextra; finalmodify =3D aggform->aggmfinalmodify; aggtranstype =3D aggform->aggmtranstype; initvalAttNo =3D Anum_pg_aggregate_aggminitval; } =C2=A0 =C2=A0 Frame options are being set to winstate=C2=A0after the initialization of pe= raggregate. (line 2504 in nodeWindowAgg.c) /* copy frame options to state node for easy access */ winstate->frameOptions =3D frameOptions; Could you kindly share the reason why this conditional case was added durin= g the initialization of per aggregate, especially considering that winstate= frameOptions is set after this initialization? Thanks Vallimaharajan G ------=_Part_236021_530436847.1711530463593 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
Hi Team,
     I am currently referring to the Postgres s= ource code (psql (PostgreSQL) 14.3) and came across a particular section re= lated to window aggregate initialization that has left me with a question. = Specifically, I noticed a conditional case in the initialization of per agg= regate (initialize_peraggregate in nodeWindowAgg.c= ) <= /span>where the w= instate frameOptions is being checked, but it appears that frameOptions is = not set before this conditional case. I observed the same behaviour in PG v= ersion 16 as well.


/*
=
* Figure out whether we want to u= se the moving-aggregate implementation,
* and collect the right set of fields from th= e pg_attribute entry.
*
* It's possible that an aggregate would supply a safe moving-aggregate<= /span>=
* implemen= tation and an unsafe normal one, in which case our hand is
* forced. Otherwise, if t= he frame head can't move, we don't need
* moving-aggregate code. Even if we'd like t= o use it, don't do so if the
* aggregate's arguments (and FILTER clause if any) conta= in any calls to
* volatile functions. Otherwise, the difference between restarting a= nd
* not r= estarting the aggregation would be user-visible.
*/
if (!OidIsVal= id(= aggform->aggminvtransfn))
use_ma_code =3D false= ; /* sine qua non */
else if (= aggform->aggmfinalmodify =3D=3D AGGMODIFY_READ_ONLY &&
aggform->= aggfinalmodify <= /span>!=3D= AGGMODIFY_READ_ONLY<= span class=3D"size" style=3D"font-size:13.3333px">)
=
use_ma_code =3D true= ; /* decision forc= ed by safety */
else = if (winstate->frameO= ptions <= span class=3D"size" style=3D"font-size:13.3333px">&= FRAMEOPTION_START_UNBOUNDED_PRECED= ING)
=
= use_ma_code = =3D= false; /*= non-moving frame head */
else if= (contain_volatile_functions((Node *) wfunc<= /span>))
use_ma_code =3D false; /* av= oid possible behavioral change */
else
use_ma_code =3D true<= sub>; /* yes, let's use it */
if (use_ma_code)
{
pera= ggstate-><= sub>transfn_oid<= span class=3D"size" style=3D"font-size:13.3333px"> =3D transfn_oid =3D aggform->= aggmtransfn;
peraggstate->invtransfn_oid =3D invtransfn= _oid =3D<= /sub>= aggform->aggminvtransfn;
peraggstate->final= fn_oid <= span class=3D"size" style=3D"font-size:13.3333px">=3D finalfn_oid =3D aggform-&g= t;aggmfinalfn= ;
=
<= span class=3D"size" style=3D"font-size:13.3333px">finalextra <= /span>=3D aggform->agg= mfinalextra;
finalmodify= =3D aggform->aggmfinalmodify;
aggtranstype =3D <= /sub>= aggform->aggmtranstype;
= initvalAttNo= =3D Anum_pg_aggregate_aggminitval;
}
   
= Frame options are being = set to w= instate=  after the initialization of peraggregate. (line 2504 in nodeWindowAgg.c)


/* copy frame options to state node for ea= sy access */
winstate-&g= t;frameOptions =3D frameOptions;

Could you kindly shar=
e the reason why this conditional case was added during the initialization =
of per aggregate, especially considering that winstate frameOptions is set =
after this initialization?

Thanks
Vallimaharajan G

------=_Part_236021_530436847.1711530463593--