On Thu, May 3, 2012 at 5:40 PM, Merlin Moncure <mmoncure@gmail.com> wrote:
> On Thu, May 3, 2012 at 10:28 AM, Ronald Hahn, DOCFOCUS INC.
> <rhahn@docfocus.ca> 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/
