Skip site navigation (1) Skip section navigation (2)

Re: Press Release

From: Rod Taylor <rbt(at)rbt(dot)ca>
To: Josh Berkus <josh(at)agliodbs(dot)com>
Cc: Scott Marlowe <scott(dot)marlowe(at)ihs(dot)com>,"Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>,Postgresql Advocacy <pgsql-advocacy(at)postgresql(dot)org>
Subject: Re: Press Release
Date: 2003-10-29 23:53:10
Message-ID: 1067471589.8672.24.camel@jester (view raw or flat)
Thread:
Lists: pgsql-advocacy
On Wed, 2003-10-29 at 18:21, Josh Berkus wrote:
> Guys,
> 
> > 
> > I agree though that the paragraph may make it sound like automatic 
> > vacuuming is a default part of the install when it isn't.
> 
> Well, like I said, we can't edit at this point, only cut.   So the question 
> is, do we cut the paragraph completely or not? 

Leave it in place. Speed during vacuum is an issue (Jan shows Vacuum can
be improved) it does not impede the 24hour availability statement.

Indexes may grow larger than wanted. Indexes do have an upper limit to
their growth for a given dataset size.

As someone who ends up with sparse indexes (multiple entries are
aggregated into a single entry but in the same index key area) I wish
data could be shuffled in the index -- but after a few years when the
data is finally removed those index pages do become available for reuse.

Of course, if you have a dataset that constantly grows, indexes could
take a fair amount of space BUT you have a constantly growing dataset
anyway. One would assume additional storage requirements would be
accounted for somewhere.


Nowhere do I read unmonitored 24/7/365 availability or ultra-fast always
peak speed availability. 7.4 may have it's speed bumps but it will be
responding to queries.

In response to

Responses

pgsql-advocacy by date

Next:From: Joshua D. DrakeDate: 2003-10-30 00:08:45
Subject: Re: Press Release
Previous:From: Tom LaneDate: 2003-10-29 23:40:11
Subject: Re: Press Release

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group