Russell wrote: > I am not sure what the effect of it being prepared will be, however I've > had much success > with the method above without the queries being prepared. Others may be > able to offer advice > about if prepare will effect it. > There are two general cases I tend to use prepared queries. First case is when there is an extremely complex plan generation step that you want to skip. IMO, this is fairly rare in the normal course of doing things.
Second case is when you have a relatively simple query that gets executed very, very frequently, such as select a,b,c from t where k. Even though the query plan is simple, using a prepared query can shave 5-15% off your query time depending on various factors (on a low latency network). If you fire off the statement a lot, this adds up. Not generally worthwhile to go this route if you are executing over a high latency network like the internet. If your application behavior can benefit from the second case, it can probably benefit from using parse/bind as well...use ExecPrepared, etc. libpq interface functions. The cumulative savings of using ExecPrepared() vs. using vanilla PQExec() (for simple queries over a high latency network) can be 50% or better. This is both from client's perspective and in server CPU load (especially when data is read from cache). This is most interesting to driver and middleware writers who broker data exchange between the application and the data. The performance minded application developer (who can make calls to the connection object) can take advantage of this however. Merlin ---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives? http://archives.postgresql.org