From: | "Strong, David" <david(dot)strong(at)unisys(dot)com> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Prepared Statement Question |
Date: | 2006-10-09 16:21:22 |
Message-ID: | B6419AF36AC8524082E1BC17DA2506E802579E44@USMV-EXCH2.na.uis.unisys.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom,
Thanks for the advice. Yes, we were looking at the possibility of saving the palloc(s) (malloc in some cases) on the statement.
David
________________________________
From: Tom Lane [mailto:tgl(at)sss(dot)pgh(dot)pa(dot)us]
Sent: Mon 10/9/2006 9:08 AM
To: Strong, David
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: [HACKERS] Prepared Statement Question
"Strong, David" <david(dot)strong(at)unisys(dot)com> writes:
> There is similar code for Parameter Lists (ParamListInfo) and Result Format Codes (rformats). Unless we're missing something, a prepared statement would probably never change once prepared.
I think you're missing something. Or are you just proposing that we
could save one palloc per Bind operation? Trust me, that ain't worth
worrying about. In any case the number of parameters appearing in Bind
could be different from the number appearing in the statement --- the
fact that that's an error doesn't allow you to not process the message
before complaining.
> Along these lines, would it also be possible to keep an Executor State and Expression Context with the statement and just reset key parts of them, rather than rebuilding them from scratch each time a prepared statement is executed?
Sounds highly bug-prone to me ... especially in the case where the
preceding execution didn't complete normally ...
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2006-10-09 16:27:21 | Re: Upgrading a database dump/restore |
Previous Message | J. Andrew Rogers | 2006-10-09 16:14:25 | Re: Interface of the R-tree in order to work with postgresql |