On Fri, Nov 13, 2009 at 9:45 PM, Craig Ringer
wrote:
> On 14/11/2009 11:55 AM, Scott Marlowe wrote:
>> On Fri, Nov 13, 2009 at 8:31 PM, Craig Ringer
>> wrote:
>>> On 13/11/2009 2:29 PM, Dave Crooke wrote:
>>>
Beware that VACUUM FULL locks an entire table at a time :-)
>>>
>>> ... and often b
On 14/11/2009 11:55 AM, Scott Marlowe wrote:
> On Fri, Nov 13, 2009 at 8:31 PM, Craig Ringer
> wrote:
>> On 13/11/2009 2:29 PM, Dave Crooke wrote:
>>
>>> Beware that VACUUM FULL locks an entire table at a time :-)
>>
>> ... and often bloats its indexes horribly. Use CLUSTER instead if you
>> need
On Fri, Nov 13, 2009 at 8:31 PM, Craig Ringer
wrote:
> On 13/11/2009 2:29 PM, Dave Crooke wrote:
>
>> Beware that VACUUM FULL locks an entire table at a time :-)
>
> ... and often bloats its indexes horribly. Use CLUSTER instead if you
> need to chop a table that's massively bloated down to size;
On 13/11/2009 2:29 PM, Dave Crooke wrote:
> Beware that VACUUM FULL locks an entire table at a time :-)
... and often bloats its indexes horribly. Use CLUSTER instead if you
need to chop a table that's massively bloated down to size; it'll be
much faster, and shouldn't leave the indexes in a mess
The FusionIO products are a little different. They are card based vs trying to
emulate a traditional disk. In terms of volatility, they have an on-board
capacitor that allows power to be supplied until all writes drain. They do not
have a cache in front of them like a disk-type SSD might. I
Fernando Hevia wrote:
Shouldn't their write performance be more than a trade-off for fsync?
Not if you have sequential writes that are regularly fsync'd--which is
exactly how the WAL writes things out in PostgreSQL. I think there's a
potential for SSD to reach a point where they can give go
2009/11/13 Greg Smith :
> As far as what real-world apps have that profile, I like SSDs for small to
> medium web applications that have to be responsive, where the user shows up
> and wants their randomly distributed and uncached data with minimal latency.
> SSDs can also be used effectively as se
Brad Nicholson wrote:
Out of curiosity, what are those narrow use cases where you think
SSD's are the correct technology?
Dave Crooke did a good summary already, I see things like this:
* You need to have a read-heavy app that's bigger than RAM, but not too
big so it can still fit on SSD
* You
[ removing -jobs from cc list as it is not appropriate for this posting ]
On Thu, Nov 12, 2009 at 3:18 AM, Brahma Prakash Tiwari
wrote:
> Hi all
>
> Why age (datfrozenxid) in postgres becomes 1073742202 not zero after vacuum
> of database.
>
> Thanks in advance
I think you're misunderstanding th
> -Mensaje original-
> Laszlo Nagy
>
> My question is about the last option. Are there any good RAID
> cards that are optimized (or can be optimized) for SSD
> drives? Do any of you have experience in using many cheaper
> SSD drives? Is it a bad idea?
>
> Thank you,
>
>Laszlo
>
Itching to jump in here :-)
There are a lot of things to trade off when choosing storage for a
database: performance for different parts of the workload,
reliability, performance in degraded mode (when a disk dies), backup
methodologies, etc. ... the mistake many people make is to overlook
the sub
Greg Smith wrote:
Karl Denninger wrote:
With the write cache off on these disks they still are huge wins for
very-heavy-read applications, which many are.
Very read-heavy applications would do better to buy a ton of RAM
instead and just make sure they populate from permanent media (say by
read
2009/11/13 Greg Smith :
> In order for a drive to work reliably for database use such as for
> PostgreSQL, it cannot have a volatile write cache. You either need a write
> cache with a battery backup (and a UPS doesn't count), or to turn the cache
> off. The SSD performance figures you've been lo
On Fri, Nov 13, 2009 at 12:22 PM, Scott Carey
> On 11/13/09 7:29 AM, "Merlin Moncure"
wrote:
>
>> On Fri, Nov 13, 2009 at 9:48 AM, Scott Marlowe
>> wrote:
>>> I think RAID6 is gonna reduce the throughput due to overhead to
>>> something far less than what a software RAID-10 would achieve.
>>
>>
Greg Smith wrote:
> Karl Denninger wrote:
>> If power is "unexpectedly" removed from the system, this is true. But
>> the caches on the SSD controllers are BUFFERS. An operating system
>> crash does not disrupt the data in them or cause corruption. An
>> unexpected disconnection of the power sou
Karl Denninger wrote:
If power is "unexpectedly" removed from the system, this is true. But
the caches on the SSD controllers are BUFFERS. An operating system
crash does not disrupt the data in them or cause corruption. An
unexpected disconnection of the power source from the drive (due to
unp
Greg Smith wrote:
> In order for a drive to work reliably for database use such as for
> PostgreSQL, it cannot have a volatile write cache. You either need a
> write cache with a battery backup (and a UPS doesn't count), or to
> turn the cache off. The SSD performance figures you've been looking
On 11/13/09 7:29 AM, "Merlin Moncure" wrote:
> On Fri, Nov 13, 2009 at 9:48 AM, Scott Marlowe
> wrote:
>> I think RAID6 is gonna reduce the throughput due to overhead to
>> something far less than what a software RAID-10 would achieve.
>
> I was wondering about this. I think raid 5/6 might
In order for a drive to work reliably for database use such as for
PostgreSQL, it cannot have a volatile write cache. You either need a
write cache with a battery backup (and a UPS doesn't count), or to turn
the cache off. The SSD performance figures you've been looking at are
with the drive'
2009/11/13 Heikki Linnakangas :
> Laszlo Nagy wrote:
>> * I need at least 32GB disk space. So DRAM based SSD is not a real
>> option. I would have to buy 8x4GB memory, costs a fortune. And
>> then it would still not have redundancy.
>
> At 32GB database size, I'd seriously consider jus
Laszlo Nagy wrote:
>* I need at least 32GB disk space. So DRAM based SSD is not a real
> option. I would have to buy 8x4GB memory, costs a fortune. And
> then it would still not have redundancy.
At 32GB database size, I'd seriously consider just buying a server with
a regular hard dr
On Fri, Nov 13, 2009 at 9:48 AM, Scott Marlowe wrote:
> I think RAID6 is gonna reduce the throughput due to overhead to
> something far less than what a software RAID-10 would achieve.
I was wondering about this. I think raid 5/6 might be a better fit
for SSD than traditional drives arrays. Her
2009/11/13 Laszlo Nagy :
> Hello,
>
> I'm about to buy SSD drive(s) for a database. For decision making, I used
> this tech report:
>
> http://techreport.com/articles.x/16255/9
> http://techreport.com/articles.x/16255/10
>
> Here are my concerns:
>
> * I need at least 32GB disk space. So DRAM bas
This is very fast.
On IT Toolbox there are many whitepapers about it.
On the ERP and DataCenter sections specifically.
We need that all tests that we do, we can share it on the
Project Wiki.
Regards
On Nov 13, 2009, at 7:02 AM, Karl Denninger wrote:
Laszlo Nagy wrote:
Hello,
I'm about to bu
Note that some RAID controllers (3Ware in particular) refuse to
recognize the MLC drives, in particular, they act as if the OCZ Vertex
series do not exist when connected.
I don't know what they're looking for (perhaps some indication that
actual rotation is happening?) but this is a potential p
Laszlo Nagy wrote:
> Hello,
>
> I'm about to buy SSD drive(s) for a database. For decision making, I
> used this tech report:
>
> http://techreport.com/articles.x/16255/9
> http://techreport.com/articles.x/16255/10
>
> Here are my concerns:
>
>* I need at least 32GB disk space. So DRAM based SS
Hello,
I'm about to buy SSD drive(s) for a database. For decision making, I
used this tech report:
http://techreport.com/articles.x/16255/9
http://techreport.com/articles.x/16255/10
Here are my concerns:
* I need at least 32GB disk space. So DRAM based SSD is not a real
option. I wou
27 matches
Mail list logo
