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