On Mar 20, 2006, at 2:44 PM, Merlin Moncure wrote:
For my use it was worth the price. However, given the speed increase
of other components since then, I don't think I'd buy one today.
Parallelism (if you can do it like Luke suggested) is the way to go.
Thats an interesting statement. My pe
> > I like their approach...ddr ram + raid sanity backup + super reliable
> > power system. Their prices are on jupiter (and i dont mean jupiter,
> > fl) but hopefully there will be some competition and the invetible
>
> Nothing unique to them. I have a 4 year old SSD from a now out-of-
> busines
On Mar 17, 2006, at 5:07 PM, Scott Marlowe wrote:
Open Source SSD via iSCSI with commodity hardware... hmmm. sounds
like
a useful project.
sh! don't give away our top secret plans!
---(end of broadcast)---
TIP 6: explain analyze is yo
On Mar 17, 2006, at 8:55 AM, Merlin Moncure wrote:
I like their approach...ddr ram + raid sanity backup + super reliable
power system. Their prices are on jupiter (and i dont mean jupiter,
fl) but hopefully there will be some competition and the invetible
Nothing unique to them. I have a 4
On Fri, 2006-03-17 at 15:28, Merlin Moncure wrote:
> On 3/17/06, Luke Lonergan <[EMAIL PROTECTED]> wrote:
> > > Now what happens as soon as you start doing random I/O? :)
> > If you are accessing 3 rows at a time from among billions, the problem you
> > have is mostly access time - so an SSD might
On 3/17/06, Luke Lonergan <[EMAIL PROTECTED]> wrote:
> > Now what happens as soon as you start doing random I/O? :)
> If you are accessing 3 rows at a time from among billions, the problem you
> have is mostly access time - so an SSD might be very good for some OLTP
> applications. However - the i
Jim,
On 3/17/06 9:36 AM, "Jim C. Nasby" <[EMAIL PROTECTED]> wrote:
> Now what happens as soon as you start doing random I/O? :)
Well - given that we've divided the data into 32 separate segments, and that
seeking is done in parallel over all 256 disk drives, random I/O rocks hard
and scales. Of
On Thu, Mar 16, 2006 at 10:44:25PM -0800, Luke Lonergan wrote:
> Jim,
>
> > PostgreSQL tuned to the max and still too slow? Database too big to
> > fit into memory? Here's the solution! http://www.superssd.com/
> > products/tera-ramsan/
>
> With a single 3 Gbyte/second infiniband connection to th
On 3/17/06, Rodrigo Madera <[EMAIL PROTECTED]> wrote:
> I don't know about you databasers that crunch in some selects, updates
> and deletes, but my personal developer workstation is planned to be a
> 4x 300GB SATA300 with a dedicated RAID stripping controller (no
> checksums, just speedup) and 4x
On 3/16/06, Jim Nasby <[EMAIL PROTECTED]> wrote:
> PostgreSQL tuned to the max and still too slow? Database too big to
> fit into memory? Here's the solution! http://www.superssd.com/
> products/tera-ramsan/
>
> Anyone purchasing one will be expected to post benchmarks! :)
I like their approach...
We got a quote for one of these (entirely for comedy value of course)
and it was in the region of £1,500,000 give or take a few thousand.
On 16 Mar 2006, at 18:33, Jim Nasby wrote:
PostgreSQL tuned to the max and still too slow? Database too big to
fit into memory? Here's the solution! http:
For God's sake buy a mainframe! =o)
On 3/17/06, Michael Stone <[EMAIL PROTECTED]> wrote:
> On Thu, Mar 16, 2006 at 10:44:25PM -0800, Luke Lonergan wrote:
> >You'd be better off with 4 x $10K servers that do 800MB/s from disk each and
> >a Bizgres MPP - then you'd do 3.2GB/s (faster than the SSD) a
On Thu, Mar 16, 2006 at 10:44:25PM -0800, Luke Lonergan wrote:
You'd be better off with 4 x $10K servers that do 800MB/s from disk each and
a Bizgres MPP - then you'd do 3.2GB/s (faster than the SSD) at a price 1/10
of the SSD, and you'd have 24TB of RAID5 disk under you.
Except, of course, tha
Josh,
On 3/16/06 9:43 PM, "Josh Berkus" wrote:
>> With a single 3 Gbyte/second infiniband connection to the device?
>
> Hey, take it easy! Jim's post was tongue-in-cheek.
You're right - I insulted his bandwidth, sorry :-)
- Luke
---(end of broadcast)---
Luke,
> With a single 3 Gbyte/second infiniband connection to the device?
Hey, take it easy! Jim's post was tongue-in-cheek.
--
Josh Berkus
Aglio Database Solutions
San Francisco
---(end of broadcast)---
TIP 5: don't forget to increase your fre
Jim,
On 3/16/06 10:44 PM, "Luke Lonergan" <[EMAIL PROTECTED]> wrote:
> Plus - need more speed? Add 12 more servers, and you'd run at 12.8GB/s and
> have 96TB of disk to work with, and you'd *still* spend less on HW and SW
> than the SSD.
And I forgot to mention that with these 16 servers you'd
Jim,
> PostgreSQL tuned to the max and still too slow? Database too big to
> fit into memory? Here's the solution! http://www.superssd.com/
> products/tera-ramsan/
With a single 3 Gbyte/second infiniband connection to the device?
You'd be better off with 4 x $10K servers that do 800MB/s from dis
On 3/16/06, Jim Nasby <[EMAIL PROTECTED]> wrote:
> PostgreSQL tuned to the max and still too slow? Database too big to
> fit into memory? Here's the solution! http://www.superssd.com/
> products/tera-ramsan/
>
> Anyone purchasing one will be expected to post benchmarks! :)
Pricing is tight-lipped,
haps more money than sense.)
Ron
-Original Message-
>From: Jim Nasby <[EMAIL PROTECTED]>
>Sent: Mar 16, 2006 1:33 PM
>To: pgsql-performance@postgresql.org
>Subject: [PERFORM] 1 TB of memory
>
>PostgreSQL tuned to the max and still too slow? Database too big to
>
Jim Nasby wrote:
PostgreSQL tuned to the max and still too slow? Database too big to
fit into memory? Here's the solution!
http://www.superssd.com/products/tera-ramsan/
Anyone purchasing one will be expected to post benchmarks! :)
And give us one :)
--
Jim C. Nasby, Sr. Engineering Consulta
PostgreSQL tuned to the max and still too slow? Database too big to
fit into memory? Here's the solution! http://www.superssd.com/
products/tera-ramsan/
Anyone purchasing one will be expected to post benchmarks! :)
--
Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED]
Pervasive So
21 matches
Mail list logo
