4G row table?

Поиск
Список
Период
Сортировка
От george young
Тема 4G row table?
Дата
Msg-id 20021219141058.11d4b693.gry@ll.mit.edu
обсуждение исходный текст
Ответы Re: 4G row table?  (Manfred Koizar <mkoi-pg@aon.at>)
Re: 4G row table?  (Josh Berkus <josh@agliodbs.com>)
Re: 4G row table?  (Ron Johnson <ron.l.johnson@cox.net>)
Re: 4G row table?  (Manfred Koizar <mkoi-pg@aon.at>)
Список pgsql-performance
[linux, 700MHz athlon, 512MB RAM, 700GB 10kRPM SCSI HW RAID, postgresql 7.2]
We're setting up a DB of IC test data, which is very simple and regular, but large.
One project (we get three or four per year) has ~4 giga bits, each specified by
a few small integer values, e.g.:
 Name       Type Values
 ----------------------
 wafer      int     1-50
 die_row    int  2-7
 die_col    int  2-7
 testtype   string (~10 different short strings)
 vdd        int  0-25
 bit_col    int  0-127
 bit_row    int  0-511
 value      bit  0 or 1

with 4 billion(4e9) rows.  I would guess to make wafer, die_row, etc. be of
type "char", probably testtype a char too with a separate testtype lookup table.
Even so, this will be a huge table.

Questions: How much overhead will there be in the table in addition to the
9 bytes of data I see?  How big will the primary index on the first seven columns
be?  Will this schema work at all?

Of course, we could pack 128 bits into an 8 byte "text" field (or should we use bit(128)?),
but lose some ease of use, especially for naive (but important) users.

Comments, suggestions?

-- George

--
 I cannot think why the whole bed of the ocean is
 not one solid mass of oysters, so prolific they seem. Ah,
 I am wandering! Strange how the brain controls the brain!
    -- Sherlock Holmes in "The Dying Detective"

В списке pgsql-performance по дате отправления:

Предыдущее
От: Joe Conway
Дата:
Сообщение: Re: EXISTS vs IN vs OUTER JOINS
Следующее
От: Josh Berkus
Дата:
Сообщение: Re: EXISTS vs IN vs OUTER JOINS