Skip site navigation (1) Skip section navigation (2)

Re: [Re] Re: PREPARE and transactions

From: "Merlin Moncure" <merlin(dot)moncure(at)rcsonline(dot)com>
To: "Jeroen T(dot) Vermeulen" <jtv(at)xs4all(dot)nl>
Cc: <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [Re] Re: PREPARE and transactions
Date: 2004-07-02 15:18:44
Message-ID: 6EE64EF3AB31D5448D0007DD34EEB34101AEB4@Herge.rcsinc.local (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
> > Right now, I'm transitioning to ExexPrepared to skip the string
> > step on the client side.  I would hate to lose that ability.
> > 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
> 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.

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
> or keep track of transactions and/or prepared statements.  Would it
> 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).



pgsql-hackers by date

Next:From: Jeroen T. VermeulenDate: 2004-07-02 15:38:33
Subject: Re: [Re] Re: PREPARE and transactions
Previous:From: Bruno Wolff IIIDate: 2004-07-02 15:03:12
Subject: Re: Adding column comment to information_schema.columns

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group