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
Views: Raw Message | Whole Thread | Download mbox | Resend email
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

Browse pgsql-advocacy by date

  From Date Subject
Next Message Joshua D. Drake 2003-10-30 00:08:45 Re: Press Release
Previous Message Tom Lane 2003-10-29 23:40:11 Re: Press Release