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
"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 tup
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?
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?
reg
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
>>> performan
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 t
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 us
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 we'
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 qui
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 p
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 t
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 sug
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
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 sugg
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 th
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 appro
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
f
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 fi
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 re
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,
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, statis
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
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
24 matches
Mail list logo
