Re: [HACKERS] Re: [QUESTIONS] Business cases
От | darrenk@insightdist.com (Darren King) |
---|---|
Тема | Re: [HACKERS] Re: [QUESTIONS] Business cases |
Дата | |
Msg-id | 9801172325.AA42672@ceodev обсуждение исходный текст |
Ответы |
Re: [HACKERS] Re: [QUESTIONS] Business cases
Re: [HACKERS] Re: [QUESTIONS] Business cases |
Список | pgsql-hackers |
> > 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
В списке pgsql-hackers по дате отправления: