On Tue, May 04, 2004 at 18:10:13 +0200,
Svenne Krap <[EMAIL PROTECTED]> wrote:
>
> In the long run, being correct is usually better than being fast (at the
> point of the implementation), as new hardware easily solves bottlenecks
> for problems not scaling exponentially.
And it isn't even cle
I would definately say solution two.
As you point out yourself, there are only for int4s (propably even
int2s), that is 8 bytes each for the int4 (if I remeber corretly), which
equals something in the 40-50 bytes range for the row w/o index.
For 15m rows, thats not much more than 750 megabytes wi
I thank you for your answer.
The more I think about it, the more I find the second option better. Just one
precision.
All tests are always done, so I always hae all columns filled with a result.
My only trouble was about size and performance. I store only a few byte with a lot of
overhead (#a
I would go for the second one. I think the size of the table is not a
problem. You will have just to write the right indexes for easy joins.
OBS: " For one assessment, I'll store 60 rows with only two useful integers
in it" ... why? Better make a "lab_test" table where you have the tab tests
and y
