From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
cc: pgsql-hackers@lists.postgresql.org
Subject: Re: Centralizing protective copying of utility statements
In-reply-to: <1057943.1623962182@sss.pgh.pa.us>
References: <931771.1623893989@sss.pgh.pa.us>
 <20210617192300.7gkpqim43gk7ernd@alap3.anarazel.de>
 <1057943.1623962182@sss.pgh.pa.us>
Comments: In-reply-to Tom Lane <tgl@sss.pgh.pa.us>
	message dated "Thu, 17 Jun 2021 16:36:22 -0400"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1059894.1623964286.1@sss.pgh.pa.us>
Date: Thu, 17 Jun 2021 17:11:26 -0400
Message-ID: <1059895.1623964286@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/1059895.1623964286%40sss.pgh.pa.us>
Precedence: bulk

I wrote:
> (In any case, if someone does get excited about this, they
> could rearrange things to push the copyObject calls into the
> individual arms of the switch in ProcessUtility.  Personally
> though I doubt it could be worth the code bloat.)

It occurred to me to try making the copying code look like

    if (readOnlyTree)
    {
        switch (nodeTag(parsetree))
        {
            case T_TransactionStmt:
                /* stmt is immutable anyway, no need to copy */
                break;
            default:
                pstmt = copyObject(pstmt);
                parsetree = pstmt->utilityStmt;
                break;
        }
    }

This didn't move the needle at all, in fact it seems maybe a
shade slower:

tps = 23502.288878 (without initial connection time)
tps = 23643.821923 (without initial connection time)
tps = 23082.976795 (without initial connection time)
tps = 23547.527641 (without initial connection time)

So I think this confirms my gut feeling that copyObject on a
TransactionStmt is negligible.  To the extent that the prior
measurement shows a real difference, it's probably a chance effect
of changing code layout elsewhere.

			regards, tom lane