time reasonably by
discarding
most of the network variance.
From: A J
To: Tom Lane
Cc: Kevin Grittner ; Scott Marlowe
; pgsql-admin@postgresql.org
Sent: Thu, September 2, 2010 3:21:24 PM
Subject: Re: [ADMIN] Confused by 'timing' results
Post
On Thu, Sep 2, 2010 at 1:17 PM, Tom Lane wrote:
> A J writes:
>> Do you think changing log_destination to syslog may make a difference
>
> It's worth trying alternatives anyway. It is odd that you are seeing
> such a slowdown when using the collector --- many people push very high
> log volumes
Cc: Kevin Grittner ; Scott Marlowe
; pgsql-admin@postgresql.org
Sent: Thu, September 2, 2010 3:17:42 PM
Subject: Re: [ADMIN] Confused by 'timing' results
A J writes:
> Do you think changing log_destination to syslog may make a difference
It's worth trying alternatives anyway.
A J writes:
> Do you think changing log_destination to syslog may make a difference
It's worth trying alternatives anyway. It is odd that you are seeing
such a slowdown when using the collector --- many people push very high
log volumes through the collector without problems. What PG version is
On Thu, Sep 2, 2010 at 1:02 PM, A J wrote:
> Do you think changing log_destination to syslog may make a difference (Kevin
> mentioned even this timing is not totally immune from network effects but if
> possible to measure should be very close to the query time) ?
At least try putting it on a dif
A J wrote:
> With this approach, I will be assuming that the query time does
> not change due to client location, which though reasonable, is
> still an assumption.
As I explained in an earlier post, the query can block on the server
due to network bandwidth or latency. So the "wall time" for
.
From: Tom Lane
To: A J
Cc: Kevin Grittner ; Scott Marlowe
; pgsql-admin@postgresql.org
Sent: Thu, September 2, 2010 3:03:33 PM
Subject: Re: [ADMIN] Confused by 'timing' results
A J writes:
> The performance as seen from the clients dropped substantially after
A J writes:
> The performance as seen from the clients dropped substantially after turning
> on
> the extra logging. The numbers were real but the performance dropped
> significantly.
> All the log related settings in postgresql.conf are below:
Hmm, what about logging_collector? (Or it might
l.org
Sent: Thu, September 2, 2010 2:31:24 PM
Subject: Re: [ADMIN] Confused by 'timing' results
Scott Marlowe wrote:
> On Thu, Sep 2, 2010 at 11:34 AM, A J wrote:
>> The problem I am trying to solve is:
>> measure accurately both the database server time + network time
>>
Scott Marlowe wrote:
> On Thu, Sep 2, 2010 at 11:34 AM, A J wrote:
>> The problem I am trying to solve is:
>> measure accurately both the database server time + network time
>> when several clients connect to the database from different
>> geographic location. All the clients hit the database
_
From: Tom Lane
To: A J
Cc: Kevin Grittner ; Scott Marlowe
; pgsql-admin@postgresql.org
Sent: Thu, September 2, 2010 2:06:43 PM
Subject: Re: [ADMIN] Confused by 'timing' results
A J writes:
> On second try, by trying to log to log_directory/log_filename by
>
A J writes:
> On second try, by trying to log to log_directory/log_filename by
> setting log_min_duration_statement=0, seems to be doing something weird. The
> durations are very very high in the file and cannot be true.
You're not being very clear here. Did the logged durations not
correspond
On Thu, Sep 2, 2010 at 11:34 AM, A J wrote:
> Kevin
> The problem I am trying to solve is:
> measure accurately both the database server time + network time when several
> clients connect to the database from different geographic location.
> All the clients hit the database simultaneously with a l
efully to not skew the measurement being tried.
Looking for suggestions to solve this.
Thank you, AJ
From: Kevin Grittner
To: Scott Marlowe ; A J
Cc: pgsql-admin@postgresql.org
Sent: Thu, September 2, 2010 12:48:58 PM
Subject: Re: [ADMIN] Confused by &#x
A J writes:
> The problem I am now facing in using log_min_duration_statement is that all
> the
> clients have to write to a single log file in the pg_log directory. So they
> have
> to wait for the other writes to happen before completing their write. This
> seems
> to be reason why the mea
A J wrote:
> I am conducting the test with several concurrent clients.
I didn't see a question in your latest email. Do you now understand
why the network affects timings? Do you have any other questions?
Is there some particular problem you're trying to solve, for which
you don't yet have a
og files are written,
#log_filename = 'postgresql-%Y-%m-%d_%H%M%S.log'# log file name pattern,
From: Scott Marlowe
To: A J
Cc: Kevin Grittner ; pgsql-admin@postgresql.org
Sent: Tue, August 31, 2010 4:02:33 PM
Subject: Re: [ADMIN] Confused by 'timing&
>> time echo '\timing \\select * from table1 where id = 123;' | psql
>> In the above query. the 'timing' will time the database time and
>> the 'time' command at the very start will time the complete time
>> for the query including network time.
>
> No, the 'timing' will say how long it took to se
On Tue, Aug 31, 2010 at 1:01 PM, A J wrote:
> OK, thanks Kevin. So to measure just the time take by database server, I
> guess I need to set the log_min_duration_statement and log_statement
> parameters in postgresql.conf
> log_min_duration_statement output should stay constant for all the differe
A J wrote:
> log_min_duration_statement output should stay constant for all the
> different clients across different geographic locations.
I'm not sure timings there will be totally immune to network speed.
The whole execution engine is designed around the top level pulling
rows from other le
.
From: Kevin Grittner
To: pgsql-admin@postgresql.org; A J
Sent: Tue, August 31, 2010 2:14:27 PM
Subject: Re: [ADMIN] Confused by 'timing' results
A J wrote:
> time echo '\timing \\select * from table1 where id = 123;' | psql
&g
A J wrote:
> time echo '\timing \\select * from table1 where id = 123;' | psql
> In the above query. the 'timing' will time the database time and
> the 'time' command at the very start will time the complete time
> for the query including network time.
No, the 'timing' will say how long it
time echo '\timing \\select * from table1 where id = 123;' | psql
I am trying to time a simple select statement from different clients located at
different places. The database is on US east-coast.
In the above query. the 'timing' will time the database time and the 'time'
command at the very s
23 matches
Mail list logo
