Using copy and paste you should be able to time both using explain
analyze to get real timings and the decision tree.
in psql issue the following command
explain analyze select ....
Dave
On Thu, Feb 24, 2011 at 1:38 PM, Maciek Sakrejda <msakrejda@truviso.com> wrote:
> A named prepared statement (which you seem to be using through
> pgAdmin) is *not* the same thing as a PreparedStatement in JDBC. Most
> pertinently, JDBC is using an unnamed portal to execute the query,
> which delays planning until the parameters are provided. I don't think
> this ever happens with a named prepared statement (it would help if
> you provided server-side logs for the pgAdmin execution as well). The
> deferred planning behavior typically works to your advantage, but you
> may have run into some edge case here.
>
> Alternately, because the unnamed portal execution actually also does
> the planning, I presume it's counted in the time of the statement
> execution, whereas in the pgAdmin case, it looks like you're only
> timing the execute, which is going against an already-planned (at
> prepare time) query, so you may be comparing apples to oranges.
>
> ---
> Maciek Sakrejda | System Architect | Truviso
>
> 1065 E. Hillsdale Blvd., Suite 215
> Foster City, CA 94404
> (650) 242-3500 Main
> www.truviso.com
>
> --
> Sent via pgsql-jdbc mailing list (pgsql-jdbc@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-jdbc
>
