> > Right now, I'm transitioning to ExexPrepared to skip the string
escaping
> > step on the client side.  I would hate to lose that ability.
ExecParams
> > is a little more work to set up (doable, though).
> 
> OTOH, if you're taking client code queries and replacing them with
> EXECUTEs (which I sort of gathered some people were doing), all it
should
> really do is move the matching activity to the server...

There is one subtle difference, and that the type resolution gets moved
from the server to the client.  ExecParams() requires a list of type
OIDs to be sent along with the statement whereas ExecPrepared() does
not.  To me, this is an inconsistent interface is set up with the
parameter name, not the oid of the parameter.  To me, it makes much more
sense to resolve by type name in all cases, but this may have some
performance implications.

> But why should anyone insist on a "transaction agnostic scenario" yet
> play with prepared statements?  That seems backwards to me.
Transactions

Because it improved statement turnaround by about 33%, and that's all I
really care about.  The conceptual case seems outweighed by practical
matters (if you move to a transactional lifetime first, that is).  This
performance difference is like having an extra processor.

> In any case, AFAICS my proposal does away with the need to wrap
anything,
> or keep track of transactions and/or prepared statements.  Would it
work
> for you?

Yes, it would.  It would actually make my life a lot easier
(notwithstanding my minor gripe with ExecParams) because I would no
longer have to deal with all the complexities surrounding prepared
statements.  This is A Good Thing, because the optimization is generic
and thus will benefit a lot more people.  

It is also more a more complex optimization model; and I think you would
have to justifiably prove that it is in the same performance league as
the current prepared statement model.  Also the current prepared
statement behavior should be retained for 7.5 and perhaps deprecated if
your viewpoint wins out (and it should).

Merlin







Fri, 2 Jul 2004 11:18:44 -0400
"Merlin Moncure" <merlin.moncure@rcsonline.com>
Re: [Re] Re: PREPARE and transactions
On Fri, Jul 02, 2004 at 11:18:44AM -0400, Merlin Moncure wrote:
 
> Yes, it would.  It would actually make my life a lot easier
> (notwithstanding my minor gripe with ExecParams) because I would no
> longer have to deal with all the complexities surrounding prepared
> statements.  This is A Good Thing, because the optimization is generic
> and thus will benefit a lot more people.  
 
Okay, off I go into the source code then.  :-)

(Which is not to say "I'll have it ready next week" but I can get an idea
of how hard it would be)


> It is also more a more complex optimization model; and I think you would
> have to justifiably prove that it is in the same performance league as
> the current prepared statement model.  Also the current prepared

True, there is a cost.  OTOH I think the added advantages could pay off
as well, e.g. sharing plans between backends (if there's not too much
locking.


> statement behavior should be retained for 7.5 and perhaps deprecated if
> your viewpoint wins out (and it should).

I guess so.  My timing isn't exactly impeccable...


Jeroen


Fri, 2 Jul 2004 17:38:33 +0200
"Jeroen T. Vermeulen" <jtv@xs4all.nl>
Re: [Re] Re: PREPARE and transactions