Jeff,
On 11/17/06 11:45 AM, "Jeff Frost" <[EMAIL PROTECTED]> wrote:
> I see many of you folks singing the praises of the Areca and 3ware SATA
> controllers, but I've been trying to price some systems and am having trouble
> finding a vendor who ships these controllers with their systems. Are you
On Nov 17, 2006, at 9:45 AM, Jeff Frost wrote:
I see many of you folks singing the praises of the Areca and 3ware
SATA controllers, but I've been trying to price some systems and am
having trouble finding a vendor who ships these controllers with
their systems. Are you rolling your own wh
Contact Pogo Linux, www.pogolinux.com. I believe they OEM and VAR
both Areca and 3ware in their systems.
3ware was bought out by AMCC, www.amcc.com
Areca cards are distributed in NA by Tekram, www.tekram.com, and are
available from them as solo items as well as in OEM storage systems.
Areca
On 17-11-2006 18:45 Jeff Frost wrote:
I see many of you folks singing the praises of the Areca and 3ware SATA
controllers, but I've been trying to price some systems and am having
trouble finding a vendor who ships these controllers with their
systems. Are you rolling your own white boxes or a
I'm trying to optimize a PostgreSQL 8.1.5 database running on an
Apple G5 Xserve (dual G5 2.3 GHz w/ 8GB of RAM), running Mac OS X
10.4.8 Server.
The queries on the database are mostly reads, and I know a larger
shared memory allocation will help performance (also by comparing it
to the p
Berner,
First, I've corrected you e-mail so that it goes to the list, and not to
me directly.
I use my PostgreSQL 8.0.4 as Catalogue-Database for Bacula.
Bacula is a Backupsoftware.
Yes. The lead contributor to Bacula is a active PostgreSQL project
participant; I'll see if he'll look into
I see many of you folks singing the praises of the Areca and 3ware SATA
controllers, but I've been trying to price some systems and am having trouble
finding a vendor who ships these controllers with their systems. Are you
rolling your own white boxes or am I just looking in the wrong places?
Simon Riggs wrote:
Do we think there is hope of improving hash indexes?
I thought about this a bit. I have an idea that the hash index might
have the fixed number of buckets specified in create index statement and
the tuples in each of these buckets should be stored in a b-tree. This
should gi
"Simon Riggs" <[EMAIL PROTECTED]> writes:
> Do we think there is hope of improving hash indexes?
Sure. They lack WAL support, which is just a small matter of
programming. And no one has ever spent any time on performance
optimization for them, but it certainly seems like there ought to be
scope
On Fri, 2006-11-17 at 08:26 -0600, Kenneth Marshall wrote:
> I certainly hold out some hope that they can improved. I would like to see
> them still included. Once they are gone, it will be much harder to ever
> add them back.
OK, you got it - keep hash indexes then.
--
Simon Riggs
Jean-Max Reymond wrote:
2006/11/10, Joshua D. Drake <[EMAIL PROTECTED]>:
I would actually suggest pg_pool over pg_pconnect.
Please, can you explain advantages of pg_pool over pg_connect ?
He said pg_pconnect (note the extra "p"). This provides permanent
connections to the database from PH
On Thu, 2006-11-16 at 17:48 -0500, Tom Lane wrote:
> AFAICS, any hash index exceeding a single segment is at serious risk.
> The fact that we've not heard gripes before suggests that no one is
> using gigabyte-sized hash indexes.
Seems so.
> But it seems mighty late in the beta cycle to be makin
12 matches
Mail list logo