On Sat, 21 Jul 2007, Tom Lane wrote:
With autovac off I see 8.3 as faster than 8.2 in pgbench.
Indeed. I'm seeing much better pgbench results from HEAD than 8.2 when I
set the configurations up identically. I'm hoping to have a comparison
set to show everyone this week.
and use -t at lea
On 7/20/07, Tom Lane <[EMAIL PROTECTED]> wrote:
I guess what we need to do is hack the emergency-recovery path for
error-during-error-processing such that it will prevent trying to print
a very long debug_query_string. Maybe we should just not try to print
the command at all in this case, or ma
On 7/20/07, Tom Lane <[EMAIL PROTECTED]> wrote:
I guess what we need to do is hack the emergency-recovery path for
error-during-error-processing such that it will prevent trying to print
a very long debug_query_string. Maybe we should just not try to print
the command at all in this case, or ma
If you want more precise timings then turn on log_duration_statement.
The logs will carry timings down to the microsecond.
Also note that this is not the correct list for such questions - this
list is about development of PostgreSQL, not use.
cheers
andrew
Kenneth Marshall wrote:
Mickael
Mickael,
Not knowing your query, it sounds like your method is working
correctly. It is quite normal to have the initial query take
longer than subsequent queries. This is a cache effect and is
what databases, in general, strive for performance-wise. I
suspect that the second time you run the quer
2007/7/21, Tom Lane <[EMAIL PROTECTED]>:
"Pavel Stehule" <[EMAIL PROTECTED]> writes:
> I was little bit surprised. Is any reason for it?
Are you sure you're comparing apples to apples? In particular the
default autovacuuming setup is entirely different. With autovac off
I see 8.3 as faster tha
"Pavel Stehule" <[EMAIL PROTECTED]> writes:
> I was little bit surprised. Is any reason for it?
Are you sure you're comparing apples to apples? In particular the
default autovacuuming setup is entirely different. With autovac off
I see 8.3 as faster than 8.2 in pgbench.
Also, remember a couple
Hello
I was little bit surprised. Is any reason for it?
Today I got:
(1) pgbench -c 30 -t 100
(2) pgbench -c 60 -t 100
(3) pgbench -c 30 -t 200
(4) pgbench -c 60 -t 200
autovacuum on
linux (fedora 7, ext3) 1GBRam, Pentium1.6M
Results 8.3 (result 8.2)
1. 300/303 (526/536)
3. 259/261 (423/42
Hello,
I am trying to get the execution time of a query by using JDBC (Java).
To do that I make the difference between the time (in milliseconds)
after the query execution and the time before the query execution.
The first time I do that, I get the real execution time, but the query
plan seems t
Tom Lane wrote:
> Gregory Stark <[EMAIL PROTECTED]> writes:
>> It seems like the impact of this is self-limiting though. The worst-case is
>> going to be something which executes an extra pfree for every tuple. Or
>> perhaps one for every expression in a complex query involving lots of
>> expressio
Hi Andrew
On Tue, 17 Jul 2007, Andrew Dunstan wrote:
> Date: Tue, 17 Jul 2007 11:30:43 -0400
> From: Andrew Dunstan <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Cc: pgsql-hackers list
> Subject: Re: [HACKERS] Backend memory growing too much
>
>
>
> [EMAIL PROTECTED] wrote:
> >
> > I don't know m
11 matches
Mail list logo
