Re: [HACKERS] Re: [QUESTIONS] Business cases

> >   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.
>

16GB?!?  Not unless your tuples are 8k.  The 8k is/was the max _tuple_ size,
but more than one tuple can be stored per block. :)

Try the formula in the FAQ to get a reasonable estimate for the table's size.

> 	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.

If the patch I sent to PATCHES is applied, then it will be a compile-time setting
and you'll need a postmaster for each database w/differing block sizes.  Not the
greatest solution, but it would work.

I almost have the "-k" option working today. Two files left to do...

backend/access/nbtree/nbtsort.c
backend/utils/adt/chunk.c

I'm being careful about pfree'ing all the stuff that I'm going to have to palloc.

Tiggers definitely do _not_ like memory leaks.

darrenk