2016-03-23 16:21 GMT+03:00 Merlin Moncure <mmonc...@gmail.com>: > On Wed, Mar 23, 2016 at 7:27 AM, Craig Ringer <cr...@2ndquadrant.com> wrote: Craig>> With PREPARE IF NOT EXISTS the client is also paying parse and network Craig>> overhead for every time you send that statement. Much better not to send it Craig>> repeatedly in the first place. > Merlin> How did you determine that? The client prepares the statement exactly Merlin> once. The problem is there's no easy way to determine if someone else Merlin> prepared it first and this patch directly addresses that.
With suggested "prepare if not exists", client would still have to send full query text along with "prepare if not exist" command. That is "network overhead". DB would still have to check if the same query with same "query name" has already been registered. Well, that query check would probably be easier than "generate execution plan", yet it can be of non-zero overhead. Craig>> I think we need to take a step back here and better define the problem Craig>> before stepping in with a proposed solution. Something that avoids the need Craig>> to spam the server with endless copies of the same PREPARE statements would Craig>> be good. +1 Merlin> A typical pattern is for the application to Merlin> prepare them all upon startup, but currently each PREPARE needs to be Merlin> wrapped with an exception handler in case someone else prepared it Merlin> first. If you plan to have "prepare if not exists" at startup only, why don't you just wrap it with exception handler then? If you plan to always issue "prepare if not exists", then you will have to send full query text for each prepare => overhead. Those repeated query texts are "endless copies of the same PREPARE statements" Craig is talking about. Merlin>The client prepares the statement exactly Merlin>once. The problem is there's no easy way to determine if someone else Merlin>prepared it first Merlin, if by "client" you somehow mean JDBC (e.g. pgjdbc), then it does track which connections have which queries prepared. So the thing we/you need might be not backend support for "prepare if not exists", but some kind of bouncer vs jdbc integration, so jdbc knows which connection it is using at each point in time. Vladimir -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
