Re: [QUESTIONS] Business cases

Tom Samplonius <tom@sdf.com>

From: Tom <tom@sdf.com>
To: The Hermit Hacker <scrappy@hub.org>
Cc: pgsql-hackers@postgresql.org, pgsql-questions@postgresql.org
Date: 1998-01-17T23:07:09Z
Lists: pgsql-hackers
On Sat, 17 Jan 1998, The Hermit Hacker wrote:

> On Sat, 17 Jan 1998, Tom wrote:
> 
> >   How are large users handling the vacuum problem?  vaccuum locks other
> > users out of tables too long.  I don't need a lot performance (a few per
> > minutes), but I need to be handle queries non-stop).
> 
> 	Not sure, but this one is about the only major thing that is continuing
> to bother me :(  Is there any method of improving this?

  vacuum seems to do a _lot_ of stuff.  It seems that crash recovery
features, and maintenance features should be separated.  I believe the
only required maintenance features are recovering space used by deleted
tuples and updating stats?  Both of these shouldn't need to lock the
database for long periods of time.

> >   Also, how are people handling tables with lots of rows?  The 8k tuple
> > size can waste a lot of space.  I need to be able to handle a 2 million
> > row table, which will eat up 16GB, plus more for indexes.
> 
> 	This oen is improved upon in v6.3, where at compile time you can stipulate
> the tuple size.  We are looking into making this an 'initdb' option instead,
> so that you can have the same binary for multiple "servers", but any database
> created under a particular server will be constrained by that tuple size.

  That might help a bit, but same tables may have big rows and some not.
For example, my 2 million row table requires only requires two date
fields, and 7 integer fields.  That isn't very much data.  However, I'd
like to be able to join against another table with much larger rows.

> Marc G. Fournier                                
> Systems Administrator @ hub.org 
> primary: scrappy@hub.org           secondary: scrappy@{freebsd|postgresql}.org 

Tom