On Tue, May 15, 2012 at 4:09 PM, John Lister wrote:
>> We've reached to the point when we would like to try SSDs. We've got a
>> central DB currently 414 GB in size and increasing. Working set does not
>> fit into our 96GB RAM server anymore.
>> So, the main question is what to take. Here what we'
We've reached to the point when we would like to try SSDs. We've got a
central DB currently 414 GB in size and increasing. Working set does not
fit into our 96GB RAM server anymore.
So, the main question is what to take. Here what we've got:
1) Intel 320. Good, but slower then current generation s
On 5/15/2012 12:16 PM, Rosser Schwarz wrote:
As the other posters in this thread have said, your best bet is
probably the Intel 710 series drives, though I'd still expect some
320-series drives in a RAID configuration to still be pretty
stupendously fast.
One thing to mention is that the 710 are
On Tue, May 15, 2012 at 8:21 AM, Віталій Тимчишин wrote:
> We are using Areca controller with BBU. So as for me, question is: Can 520
> series be set up to handle fsyncs correctly?
No.
The cause for capacitors on SSD logic boards is that fsyncs aren't
flushed to NAND media, and hence persisted,
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
>>> Is it established practice in the Postgres world to separate indexes
>>> from tables? I would assume that the reasoning of Richard Foote -
>>> albeit for Oracle databases - is also true for Postgres:
>
>> Yes, it's an established practice. I
On Tue, May 15, 2012 at 12:08 PM, David Boreham wrote:
>> We've reached to the point when we would like to try SSDs. We've got a
>> central DB currently 414 GB in size and increasing. Working set does not fit
>> into our 96GB RAM server anymore.
>> So, the main question is what to take. Here what
On 5/15/2012 9:21 AM, Віталій Тимчишин wrote:
We've reached to the point when we would like to try SSDs. We've got a
central DB currently 414 GB in size and increasing. Working set does
not fit into our 96GB RAM server anymore.
So, the main question is what to take. Here what we've got:
1) I
Hello, all.
We've reached to the point when we would like to try SSDs. We've got a
central DB currently 414 GB in size and increasing. Working set does not
fit into our 96GB RAM server anymore.
So, the main question is what to take. Here what we've got:
1) Intel 320. Good, but slower then current
Hi,
On Tue, May 15, 2012 at 12:57 PM, Andres Freund wrote:
> I would rather suggest going with a suming table if you need to do something
> like that:
>
> sequence_id | value
> 1 | 3434334
> 1 | 1
> 1 | -1
> 1 | 1
> 1 | 1
> ...
>
> You then can get the current value with SELECT SUM(value) WHERE
On Tuesday, May 15, 2012 08:29:11 AM Віталій Тимчишин wrote:
> 2012/5/13 Robert Klemme
>
> > On Sun, May 13, 2012 at 10:12 AM, Віталій Тимчишин
> >
> > wrote:
> > > 2012/5/11 Robert Klemme
> > >
> > >> On the contrary: what would be the /advantage/ of being able to create
> > >> millions of s
10 matches
Mail list logo
