On Thu, May 3, 2012 at 5:40 PM, Merlin Moncure <mmoncure(at)gmail(dot)com> wrote:
> On Thu, May 3, 2012 at 10:28 AM, Ronald Hahn, DOCFOCUS INC.
> <rhahn(at)docfocus(dot)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:
Using the PG client remotely with "\timing on" might be an even better idea.
remember.guy do |as, often| as.you_can - without end
In response to
pgsql-performance by date
|Next:||From: Thomas Kellerer||Date: 2012-05-07 12:11:53|
|Subject: Re: Result Set over Network Question|
|Previous:||From: Martin Grotzke||Date: 2012-05-07 09:37:05|
|Subject: Re: Several optimization options (config/hardware)|