Zoolin Lin wrote:
Hi,
I have database with a huge amount of data so i'm trying to make it
as fast as possible and minimize space.
One thing i've done is join on a prepopulated date lookup table to
prevent a bunch of rows with duplicate date columns. Without this I'd
have about 2500 rows per hou
* James Mansion:
> If I were to use a filesystem with noatime etc and little non-sql traffic,
> does the physical update pattern tend to have hot sectors that will tend to
> wear out CF?
Thanks to the FAT file system and its update pattern, most (if not
all) CF disks implement wear leveling nowad
thanks for your reply
> Primary table is all integers like:
>
> date id | num1 | num2 | num3 | num4 | num5 | num6 | num7 | num 8
> -
> primary key is on date to num->6 columns
>>What types are num1-
Zoolin Lin wrote:
thanks for your reply
Primary table is all integers like:
date id | num1 | num2 | num3 | num4 | num5 | num6 | num7 | num 8
-
primary key is on date to num->6 columns
What typ
At 05:18 PM 3/6/2007, James Mansion wrote:
I see that one can now get compact flash to SATA connectors.
If I were to use a filesystem with noatime etc and little non-sql traffic,
does the physical update pattern tend to have hot sectors that will tend to
wear out CF?
Most flash RAMs have drivers
Much better to use flash RAM for read heavy applications.
Even there you have to be careful that seek performance, not
throughput, is what is gating your day to day performance with those
tables.
Isn't precisely there where Flash disks would have *the* big advantage??
I mean, access time
> Or are these Flash disks so slow that they compare to the HD's latency
> figures?
On sequential read speed HDs outperform flash disks... only on random
access the flash disks are better. So if your application is a DW one,
you're very likely better off using HDs.
Cheers,
Csaba.
Le mardi 6 mars 2007 23:18, James Mansion a écrit :
> I see that one can now get compact flash to SATA connectors.
I can suggest you to have a look at Gigabyte i-ram .
We use it on a website with higth traffic with lot of succes. Unfortunely, I
can not provide any benchmark...
>
> If I were to use
Jeff Cole <[EMAIL PROTECTED]> writes:
> Hi Tom, you are correct, the distribution is uneven... In the 13k
> symptom_reports rows, there are 105 distinct symptom_ids. But the
> first 8k symptom_reports rows only have 10 distinct symptom_ids.
> Could this cause the problem and would there b
Tom Lane wrote:
> Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes:
>> Arjen van der Meijden wrote:
>>> Stefan Kaltenbrunner wrote:
ouch - do I read that right that even after tom's fixes for the
"regressions" in 8.2.0 we are still 30% slower then the -HEAD checkout
from the middle of
Thank you for the reply
>> Primary table is all integers like:
>>
>> date id | num1 | num2 | num3 | num4 | num5 | num6 | num7 | num 8
>> -
>> primary key is on date to num->6 columns
>
>>> What typ
Zoolin Lin wrote:
Thank you for the reply
Primary table is all integers like:
date id | num1 | num2 | num3 | num4 | num5 | num6 | num7 | num 8
-
primary key is on date to num->6 columns
What ty
>WARNING: modern TOtL flash RAMs are only good for ~1.2M writes per
>memory cell. and that's the =good= ones.
>Using flash RAM for write heavy applications like OLTP, or for WAL,
>etc can be very dangerous
Well, that's why I suggested that the WAL would stream to a hard disk
array, where the lar
13 matches
Mail list logo
