Re: [GENERAL] Benchmarks

Hi,

I had posted a message yesterday on 4 things which bugged me about postgres
while running a 24x7 app.
This discussion has degenrated into a discussion on vacuum.
Now here is a person (Michael), who wants help to decide whether postgres is
the right choice or not. It would be nice to help him... Please contribute
to helping him decide. I want more responses on pg experiences with 24x7
apps.

Bye,

Murali

-----Original Message-----
From: The Hermit Hacker <scrappy(at)hub(dot)org>
To: Differentiated Software Solutions Pvt. Ltd. <diffs(at)vsnl(dot)com>
Cc: Michael Cornelison <mcornel(at)magnify(dot)com>; pgsql-general(at)hub(dot)org
<pgsql-general(at)hub(dot)org>; Kimi <kimi(at)intercept(dot)co(dot)in>
Date: 06 January 2000 19:05
Subject: Re: [GENERAL] Benchmarks

>On Thu, 6 Jan 2000, Differentiated Software Solutions Pvt. Ltd. wrote:
>
>> b) There are quite a few things which you'd take for granted in other DBs
>> which postgres does not have. Quite late in the day I was shocked to find
>> that postgres does not have roll-forward transaction logging. They have
>> Multi-version concurrency control and rollback support but you can't
restore
>> a backup and play logs !!
>
>Being worked on...as memory serves, should be in v7.1, as its part of the
>WAL work that Vadim is doing...scheduale: this summer
>
>> c) Another issue which rankles me a lot is that postgres maintains
different
>> tables in different files. I remember lots of debate on this issue
between
>> 1993 and 95 and most DBMS's have settled down into having all tables
within
>> their own file structure... presumably to take over buffering and other
>> mechanisms from the OS onto themselves. I have even read literature where
>> Oracle and DB2 allow U to create DB's on raw UNIX partitions. I'm not
sure
>> whether they are still used.
>
>There are several schools of thought on this one...I've read documentation
>from Oracle that recommends against doing this, since the operating
>itself, in most cases, will do a much better job of disk I/O...there are
>generally ways of tweaking your OS to increase various things like disk
>buffering and what not...
>
>> d) Postgres manual recommends a nightly vacuum. I read this also a bit
>> late. This is equivalent of rebuild database. While this is in
>> progress all other clients wait for vacuum release locks. This is
>> really a handicap for a 24x7 app.
>
>rebuild? first off, vacuum is a 'cleanup tool'...it goes through and
>removes unwanted/junk/deleted records from the database...if you do alot
>of update/delete operations, then, yes, do a vacuum reasonably
>often. nightly though? depends on how much your data changes. a vacuum
>gives you nothing really on a database that is purely insert data.
>
>actually, there has been talk about, and work started on, getting rid of
>the 'locking' issue...with the MVCC code, the lock *shouldn't* be required
>anymore, but Tom Lane(?) did some preliminary work on removing this for
>v7.0 and ran into a few roadblocks, especially where there was the risk of
>simultaneous vacuum's happening...wasn't a pretty sight, if memory
>serves...
>
>> At the same time.... postgres would be a great choice when you have
>> a) hardware resource constraints
>> b) Less money to buy software
>> c) your app is not mission critical and 24x7.
>
>I love these two works "mission critical"...I run several applications
>that clients consider to be mission critical, the least of which are two
>accounting systems for dial-up ISPs...about the only time their databases
>go down is when we upgrade or have to reboot the physical machine...
>
>
>Marc G. Fournier ICQ#7615664 IRC Nick:
Scrappy
>Systems Administrator @ hub.org
>primary: scrappy(at)hub(dot)org secondary:
scrappy(at){freebsd|postgresql}.org
>