Re: [Re] Re: PREPARE and transactions - Mailing list pgsql-hackers

From Jeroen T. Vermeulen
Subject Re: [Re] Re: PREPARE and transactions
Date
Msg-id 20040702153833.GA44628@xs4all.nl
Whole thread Raw
In response to Re: [Re] Re: PREPARE and transactions  ("Merlin Moncure" <merlin.moncure@rcsonline.com>)
List pgsql-hackers
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



pgsql-hackers by date:

Previous
From: "Andrew Dunstan"
Date:
Subject: Re: compile errors in new PL/Pler
Next
From: Thomas Swan
Date:
Subject: Re: Nested Transactions, Abort All