Re: [GENERAL] Benchmarks - Mailing list pgsql-general

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@hub.org           secondary: scrappy@{freebsd|postgresql}.org