Re: VACUUM, 24/7 availability and 7.2 - Mailing list pgsql-general

From wsheldah@lexmark.com
Subject Re: VACUUM, 24/7 availability and 7.2
Date
Msg-id 200110102022.QAA23273@interlock2.lexmark.com
Whole thread Raw
In response to VACUUM, 24/7 availability and 7.2  (Ian Barwick <SUNGLASSESbarwick@gmx.net>)
Responses Re: VACUUM, 24/7 availability and 7.2
Re: VACUUM, 24/7 availability and 7.2
List pgsql-general

Just to keep things in perspective, how large are your current databases, and
what do you or the company consider to be a signficant length of time?  Right
now I have a development database with just a few thousand records of test data,
and vacuum takes just a very few seconds a day.  I think I recall hearing on
this list of it taking a minute or three for databases several gigabytes in
size.  For some sites this would be tolerable, for others it wouldn't.

I'm also interested to hear what the future holds for vacuum.  If nothing else,
it couldn't hurt postgresql's public relations.  :-)

--Wes Sheldahl





Ian Barwick <SUNGLASSESbarwick%gmx.net@interlock.lexmark.com> on 10/10/2001
07:27:56 AM

To:   pgsql-general%postgresql.org@interlock.lexmark.com
cc:    (bcc: Wesley Sheldahl/Lex/Lexmark)
Subject:  [GENERAL] VACUUM, 24/7 availability and 7.2


I'm doing some work for a smallish company which conducts
its business largely online. Currently they have a legacy
mishmash of Oracle and MySQL databases which they wish
to unify one one platform (RDBMS with client access via
browser and custom serverside applications for employees
and customers).

PostgreSQL would be my primary candidate. However the company's
operating requirments mean that the data needed for interaction
with customers / website users must be available on a 24/7 basis.
This is primarily a) data related to product ordering and
tables for storing order data; and b) website user authentication
and personalisation data (logins, user preferences etc).

It is therefore not an option to have these databases offline
at regular intervals for any significant length of time for
VACUUMing. Replicating data to say MySQL databases is
technically feasible, at least in the case of b) above, but
not desirable. Are there any existing "native" PostgreSQL solutions
to this problem?

More importantly, what is the situation on VACUUM for release 7.2?
It seems from the pgsql-hackers list that there are plans for
a none-exclusively locking VACUUM, e.g.:


http://groups.google.com/groups?q=vacuum&hl=en&group=comp.databases.postgresql.hackers&rnum=1&selm=12833.990140724%40sss.pgh.pa.us


(sorry about the long URL); how far advanced are they, and is
there any kind of release schedule for 7.2?

Any answers (or pointers thereto, haven't found any myself :-()
much appreciated


Ian Barwick

--

Remove SUNGLASSES to reply ;-)

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org





pgsql-general by date:

Previous
From: Doug McNaught
Date:
Subject: Re: VACUUM, 24/7 availability and 7.2
Next
From: "Mitch Vincent"
Date:
Subject: Re: Where to count