On Sun, 2007-07-22 at 08:53 -0700, Josh Berkus wrote:
Pavel Stehule wrote:
Hello,
I checked my tests again I have different results. Now I tested
PostgreSQL on dedicated server. Now 8.3 is about 20% faster. I didn't
see strong impression of autovacuum. All numbers are approximate
On Sat, 2007-07-21 at 13:30 -0400, Tom Lane wrote:
Note to all: we ***HAVE TO*** settle on some reasonable default
vacuum_cost_delay settings before we can ship 8.3. With no cost delay
and two or three workers active, 8.3's autovac does indeed send
performance into the tank.
Couple of
Simon Riggs wrote:
The bad thing about having multiple autovacuum daemons active is that
you can get two large VACUUMs running at the same time. This gives you
the same small-VACUUM-starvation problem we had before, but now the
effects of two VACUUMs kill performance even more. I would suggest
On Mon, 2007-07-23 at 10:04 +0100, Heikki Linnakangas wrote:
Simon Riggs wrote:
The bad thing about having multiple autovacuum daemons active is that
you can get two large VACUUMs running at the same time. This gives you
the same small-VACUUM-starvation problem we had before, but now the
Simon Riggs wrote:
The bad thing about having multiple autovacuum daemons active is that
you can get two large VACUUMs running at the same time. This gives you
the same small-VACUUM-starvation problem we had before, but now the
effects of two VACUUMs kill performance even more. I would
On Mon, 2007-07-23 at 12:00 -0400, Alvaro Herrera wrote:
Simon Riggs wrote:
The bad thing about having multiple autovacuum daemons active is that
you can get two large VACUUMs running at the same time. This gives you
the same small-VACUUM-starvation problem we had before, but now the
Simon Riggs wrote:
On Mon, 2007-07-23 at 12:00 -0400, Alvaro Herrera wrote:
Simon Riggs wrote:
The bad thing about having multiple autovacuum daemons active is that
you can get two large VACUUMs running at the same time. This gives you
the same small-VACUUM-starvation problem we had
On 7/23/07, Alvaro Herrera [EMAIL PROTECTED] wrote:
Certainly it doesn't prevent starvation completely -- really there is no
way to completely prevent starvation unless you have as many workers as
you have tables, and one disk for each. What DSM does do is let the big
tables be vacuumed
On Jul 23, 2007, at 1:40 AM, Simon Riggs wrote:
Potential solution: Each autovac worker gets a range of table sizes
they
are allowed to VACUUM.
Anyone putting thought into this should check the archives; there was
quite a bit of discussion around it. For 8.3 we decided to KISS so
that
On Jul 22, 2007, at 8:54 AM, Josh Berkus wrote:
Tom,
Note to all: we ***HAVE TO*** settle on some reasonable default
vacuum_cost_delay settings before we can ship 8.3. With no cost
delay
and two or three workers active, 8.3's autovac does indeed send
performance into the tank.
I've been
Pavan Deolasee wrote:
On 7/23/07, Alvaro Herrera [EMAIL PROTECTED] wrote:
Certainly it doesn't prevent starvation completely -- really there is no
way to completely prevent starvation unless you have as many workers as
you have tables, and one disk for each. What DSM does do is let the big
Jim Nasby wrote:
On Jul 22, 2007, at 8:54 AM, Josh Berkus wrote:
Tom,
Note to all: we ***HAVE TO*** settle on some reasonable default
vacuum_cost_delay settings before we can ship 8.3. With no cost delay
and two or three workers active, 8.3's autovac does indeed send
performance into the
Alvaro Herrera [EMAIL PROTECTED] writes:
OK, 20ms it is then. Here is a patch. I am taking the liberty to also
lower the vacuum and analyze threshold default values to 50, per
previous discussion.
Patch probably needs to touch docs (config.sgml at least) too?
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
OK, 20ms it is then. Here is a patch. I am taking the liberty to also
lower the vacuum and analyze threshold default values to 50, per
previous discussion.
Patch probably needs to touch docs (config.sgml at least) too?
That's
Alvaro Herrera [EMAIL PROTECTED] writes:
Alvaro Herrera [EMAIL PROTECTED] writes:
I am taking the liberty to also lower the vacuum and analyze threshold
default values to 50, per previous discussion.
Did we also reach any consensus about lowering the percentage of dead tuples
in a table
Gregory Stark wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Alvaro Herrera [EMAIL PROTECTED] writes:
I am taking the liberty to also lower the vacuum and analyze threshold
default values to 50, per previous discussion.
Did we also reach any consensus about lowering the percentage of dead
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
Hello,
I checked my tests again I have different results. Now I tested
PostgreSQL on dedicated server. Now 8.3 is about 20% faster. I didn't
see strong impression of autovacuum. All numbers are approximate
only. I did pgbench 3x for folowing configuration: (autovacuum on,
autovacuum off,
Pavel Stehule wrote:
Hello,
I checked my tests again I have different results. Now I tested
PostgreSQL on dedicated server. Now 8.3 is about 20% faster. I didn't
see strong impression of autovacuum. All numbers are approximate
only. I did pgbench 3x for folowing configuration: (autovacuum on,
Tom,
Note to all: we ***HAVE TO*** settle on some reasonable default
vacuum_cost_delay settings before we can ship 8.3. With no cost delay
and two or three workers active, 8.3's autovac does indeed send
performance into the tank.
I've been using 20ms for most of my setups. That's aimed at
Greg Smith [EMAIL PROTECTED] writes:
I'd want a set of 3 at each configuration because even with longer runs,
you occasionally get really odd results. Until you have 3 it can be
unclear which is the weird one.
Yeah, pgbench results are notoriously unrepeatable. One issue is that
the first
On Sun, 22 Jul 2007, Tom Lane wrote:
There seems to be also some of the good average but bad worst case
behavior that Josh and others have pointed out in bigger benchmarks.
I've always assumed this was due to checkpointing
At lot of variation is from checkpoints, some comes from the index
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
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 than 8.2
24 matches
Mail list logo
