From: | Ron Johnson <ron(dot)l(dot)johnson(at)cox(dot)net> |
---|---|
To: | PgSQL Performance ML <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: 4G row table? |
Date: | 2002-12-19 19:36:36 |
Message-ID: | 1040326596.28772.186.camel@haggis |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On Thu, 2002-12-19 at 13:10, george young wrote:
> [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.
How many records per day will be inserted?
Will they ever be updated?
Do you have to have *ALL* 4 billion records in the same table at the
same time? As Josh Berkus mentioned, wafer thru bit_col can be
converted to INT2, if you make testtype use a lookup table; thus, each
tuple could be shrunk to 20 bytes, plus 24 bytes per tuple (in v7.3)
that would make the table a minimum of 189 billion bytes, not
including index!!!
Rethink your solution...
One possibility would to have a set of tables, with names like:
TEST_DATA_200301
TEST_DATA_200302
TEST_DATA_200303
TEST_DATA_200304
TEST_DATA_200305
TEST_DATA_200306
TEST_DATA_200307
TEST_DATA_<etc>
Then, each month do "CREATE VIEW TEST_DATA AS TEST_DATA_yyyymm" for the
current month.
> 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
>
--
+---------------------------------------------------------------+
| Ron Johnson, Jr. mailto:ron(dot)l(dot)johnson(at)cox(dot)net |
| Jefferson, LA USA http://members.cox.net/ron.l.johnson |
| |
| "My advice to you is to get married: If you find a good wife, |
| you will be happy; if not, you will become a philosopher." |
| Socrates |
+---------------------------------------------------------------+
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2002-12-19 22:46:20 | Re: EXISTS vs IN vs OUTER JOINS |
Previous Message | jasiek | 2002-12-19 19:28:30 | Re: EXISTS vs IN vs OUTER JOINS |