On Thu, May 3, 2012 at 5:40 PM, Merlin Moncure <mmoncure@xxxxxxxxx> wrote: > On Thu, May 3, 2012 at 10:28 AM, Ronald Hahn, DOCFOCUS INC. > <rhahn@xxxxxxxxxxx> wrote: >> After some testing using wiershark (poor mans profiler) to see what was >> going on with the network I found that it was the tools I've been using. >> Both Aqua and PGadminIII have a large overhead per column to get the meta >> data. MSSQL sends that data upfront so the impact isn't as bad. I'm not sure >> if it's a limitation of the pgsql protocol vs tds or a limitation of Aqua or >> a combination of both. At any rate it turns out not to be part of the >> problem I'm having with my software stalling out so I'm back to Square one >> with my problem. So, Ronald, are you saying the different approach to meta data transfer is _not_ the issue? > ok, let's figure out what the issue is then. first, let's make sure > it isn't the server that's stalling: configure > log_min_duration_statement with an appropriate value so you start > catching queries that are taking longer then you think the should be. > also some client side logging directly wrapping the SQL invocation > couldn't hurt. is your application jdbc? Ronald said ODBC in his first posting. But since ADS seems to support JDBC as well trying that might be a good test to get another data point. Alternative tools for JDBC tests: http://squirrel-sql.sourceforge.net/ http://www.oracle.com/technetwork/developer-tools/sql-developer/overview/index.html Using the PG client remotely with "\timing on" might be an even better idea. Kind regards robert -- remember.guy do |as, often| as.you_can - without end http://blog.rubybestpractices.com/ -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
