Re: [HACKERS] Prepared Statement Question

[Strong, David]

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:[EMAIL PROTECTED]
Sent: Mon 10/9/2006 9:08 AM
To: Strong, David
Cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Prepared Statement Question 



"Strong, David" <[EMAIL PROTECTED]> 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



---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings

Re: [HACKERS] Prepared Statement Question

[Tom Lane]

"Strong, David" <[EMAIL PROTECTED]> 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

---(end of broadcast)---
TIP 4: Have you searched our list archives?

   http://archives.postgresql.org

[HACKERS] Prepared Statement Question

[Strong, David]

We have a question regarding prepared statements. The following code is located 
in src/backend/tcop/postgres.c:
 
 
/* Get the parameter format codes */
numPFormats = pq_getmsgint(input_message, 2);
if (numPFormats > 0)
{
int i;
pformats = (int16 *) palloc(numPFormats * sizeof(int16));
for (i = 0; i < numPFormats; i++)
pformats[i] = pq_getmsgint(input_message, 2);
}

 
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. 
 
Would there be any issue or benefit moving the allocation of these buffers to 
the PreparedStatement structure so they stay with the prepared statement 
throughout its life? There is probably the question of named versus unnamed 
prepared statements, but is there anything else that we might be missing?
 
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?
 
Thanks
 
David

---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster