From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Centralizing protective copying of utility statements |
Date: | 2021-06-17 21:11:26 |
Message-ID: | 1059895.1623964286@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2021-06-17 21:24:55 | Re: Patch for bug #17056 fast default on non-plain table |
Previous Message | Andres Freund | 2021-06-17 21:08:34 | Re: Centralizing protective copying of utility statements |