On Tue, Nov 24, 2009 at 7:35 PM, Greg Smith wrote:
> Scott Marlowe wrote:
>>
>> As far as drives go we've been really happy with WD of late, they make
>> large enterprise class SATA drives that don't pull a lot of power
>> (green series) and fast SATA drives that pull a bit more but are
>> faster
Jochen Erwied wrote:
- Promise Technology Supertrak ES4650 + additional BBU
- Adaptec RAID 5405 SGL/256 SATA/SAS + additional BBU
- Adaptec RAID 5405Z SGL/512 SATA/SAS
I've never seen a Promise controller that had a Linux driver you would
want to rely on under any circumstances. Adaptec used
Scott Marlowe wrote:
As far as drives go we've been really happy with WD of late, they make
large enterprise class SATA drives that don't pull a lot of power
(green series) and fast SATA drives that pull a bit more but are
faster (black series).
Be careful to note the caveat that you need their *
Matthew Wakeling wrote:
People have mentioned Areca as making good RAID controllers. We're
looking at the "Areca ARC-1220 PCI-Express x8 SATA II" as a
possibility. Does anyone have an opinion on whether it is a turkey or
a star?
Performance should be OK but not great compared with some of the n
Even though the column in question is not unique on t2 could you not
index it? That should improve the performance of the inline query.
Are dates applicable in any way? In some cases adding a date field,
partitioning or indexing on that and adding where date>x days. That
can be an effectiv
Jochen Erwied wrote:
Tuesday, November 24, 2009, 10:34:00 PM you wrote:
Aberdeen is the builder I use. They'll put any card in you want
(within reason) including our preference here, Areca. Perhaps you
meant Areca?
I knew Areca only for their internal arrays (which o
Tuesday, November 24, 2009, 10:34:00 PM you wrote:
> Aberdeen is the builder I use. They'll put any card in you want
> (within reason) including our preference here, Areca. Perhaps you
> meant Areca?
I knew Areca only for their internal arrays (which one of our customers
uses for his 19" system
The problem with RAID-5 or RAID-6 is not the normal speed operation, it's
the degraded performance when there is a drive failure. This includes
read-only scenarios. A DB server getting any kind of real use will
effectively appear to be down to client apps if it loses a drive from that
RAID set.
Ba
On Tue, Nov 24, 2009 at 1:59 PM, Jochen Erwied
wrote:
> Tuesday, November 24, 2009, 9:05:28 PM you wrote:
>
>> Have you searched the -performance archives for references to them?
>> I'm not that familiar with Adaptec RAID controllers. Not requiring a
>> battery check / replacement is nice.
>
> Ei
- "Scott Marlowe" escreveu:
> On Tue, Nov 24, 2009 at 1:37 PM, Ing. Marcos Ortiz Valmaseda
> wrote:
> > Do you expose that performance issued caused by RAID 5? Because this
> is one
> > of our solutions here on my country to save the data of our
> PostgreSQL
> > database. Which model do you
Tuesday, November 24, 2009, 9:05:28 PM you wrote:
> Have you searched the -performance archives for references to them?
> I'm not that familiar with Adaptec RAID controllers. Not requiring a
> battery check / replacement is nice.
Either I searched for the wrong terms, or there isn't really that
On Tue, Nov 24, 2009 at 1:37 PM, Ing. Marcos Ortiz Valmaseda
wrote:
> Do you expose that performance issued caused by RAID 5? Because this is one
> of our solutions here on my country to save the data of our PostgreSQL
> database. Which model do you recommend ? RAID 0,RAID 1, RAID 5 or RAID 10?
R
Gurgel, Flavio escribió:
- "Richard Neill" escreveu:
Matthew Wakeling wrote:
We're about to purchase a new server to store some of our old
databases,
and I was wondering if someone could advise me on a RAID card. We
want
to make a 6-drive SATA RAID arra
Lorenzo Allegrucci escribió:
Matthew Wakeling wrote:
On Mon, 23 Nov 2009, Lorenzo Allegrucci wrote:
Anyway, how can I get rid those "idle in transaction" processes?
Can I just kill -15 them or is there a less drastic way to do it?
Are you crazy? Sure, if you want to destroy all of the changes
On Tue, Nov 24, 2009 at 12:28 PM, Jochen Erwied
wrote:
>
> Since I'm currently looking at upgrading my own database server, maybe some
> of the experts can give a comment on one of the following controllers:
>
> - Promise Technology Supertrak ES4650 + additional BBU
> - Adaptec RAID 5405 SGL/256 S
Since I'm currently looking at upgrading my own database server, maybe some
of the experts can give a comment on one of the following controllers:
- Promise Technology Supertrak ES4650 + additional BBU
- Adaptec RAID 5405 SGL/256 SATA/SAS + additional BBU
- Adaptec RAID 5405Z SGL/512 SATA/SAS
My
On Tue, Nov 24, 2009 at 10:23 AM, Matthew Wakeling wrote:
>
> We're about to purchase a new server to store some of our old databases, and
> I was wondering if someone could advise me on a RAID card. We want to make a
> 6-drive SATA RAID array out of 2TB drives, and it will be RAID 5 or 6
> becaus
- "Richard Neill" escreveu:
> Matthew Wakeling wrote:
> >
> > We're about to purchase a new server to store some of our old
> databases,
> > and I was wondering if someone could advise me on a RAID card. We
> want
> > to make a 6-drive SATA RAID array out of 2TB drives, and it will be
> R
On Nov 24, 2009, at 9:23 AM, Matthew Wakeling wrote:
We're about to purchase a new server to store some of our old
databases, and I was wondering if someone could advise me on a RAID
card. We want to make a 6-drive SATA RAID array out of 2TB drives,
and it will be RAID 5 or 6 because there
Matthew Wakeling wrote:
We're about to purchase a new server to store some of our old databases,
and I was wondering if someone could advise me on a RAID card. We want
to make a 6-drive SATA RAID array out of 2TB drives, and it will be RAID
5 or 6 because there will be zero write traffic. The
We're about to purchase a new server to store some of our old databases,
and I was wondering if someone could advise me on a RAID card. We want to
make a 6-drive SATA RAID array out of 2TB drives, and it will be RAID 5 or
6 because there will be zero write traffic. The priority is stuffing as
On Tuesday 24 November 2009, Thom Brown wrote:
>
> It's a shame there isn't a LIMIT option on DELETE so this can be done in
> small batches.
delete from table where pk in (select pk from table where delete_condition
limit X);
--
"No animals were harmed in the recording of this episode. We tri
On Tue, 24 Nov 2009, Denis Lussier wrote:
IMHO the client application is already confused and it's in Prod.
Shouldn't he perhaps terminate/abort the IDLE connections in Prod and
work on correcting the problem so it doesn't occur in Dev/Test??
The problem is, the connection isn't just IDLE - it
On Tue, Nov 24, 2009 at 3:19 PM, Thom Brown wrote:
> 2009/11/24 Luca Tettamanti
>
> On Tue, Nov 24, 2009 at 3:59 PM, Jerry Champlin
>> wrote:
>> > You may want to consider using partitioning. That way you can drop the
>> > appropriate partition and never have the overhead of a delete.
>>
>> Hu
Matthew Wakeling wrote:
On Mon, 23 Nov 2009, Lorenzo Allegrucci wrote:
Anyway, how can I get rid those "idle in transaction" processes?
Can I just kill -15 them or is there a less drastic way to do it?
Are you crazy? Sure, if you want to destroy all of the changes made to
the database in that
You may want to consider using partitioning. That way you can drop the
appropriate partition and never have the overhead of a delete.
Jerry Champlin|Absolute Performance Inc.|Mobile: 303-588-2547
-Original Message-
From: pgsql-performance-ow...@postgresql.org
[mailto:pgsql-performance-o
2009/11/24 Luca Tettamanti
> On Tue, Nov 24, 2009 at 3:59 PM, Jerry Champlin
> wrote:
> > You may want to consider using partitioning. That way you can drop the
> > appropriate partition and never have the overhead of a delete.
>
> Hum, I don't think it's doable in my case; the partitioning is
On Tue, Nov 24, 2009 at 3:59 PM, Jerry Champlin
wrote:
> You may want to consider using partitioning. That way you can drop the
> appropriate partition and never have the overhead of a delete.
Hum, I don't think it's doable in my case; the partitioning is not
know a priori. First t1 is fully pop
Hello,
I've run in a severe performance problem with the following statement:
DELETE FROM t1 WHERE t1.annotation_id IN (
SELECT t2.annotation_id FROM t2)
t1 contains about 48M record (table size is 5.8GB), while t2 contains about 60M
record (total size 8.6GB). annotation_id is the PK in t
2009/11/24 ramasubramanian :
> Dear All.
> Can any one give me dynamic sql in postgres stored procedure using
> "USING CLAUSE"
CREATE TABLE tab(a integer);
CREATE OR REPLACE FUNCTION foo(_a integer)
RETURNS void AS $$
DECLARE r record;
BEGIN
FOR r IN EXECUTE 'SELECT * FROM tab WHERE a = $1'
Dear All.
Can any one give me dynamic sql in postgres stored procedure using "USING
CLAUSE"
Regards,
Ram
On Mon, 23 Nov 2009, Lorenzo Allegrucci wrote:
Anyway, how can I get rid those "idle in transaction" processes?
Can I just kill -15 them or is there a less drastic way to do it?
Are you crazy? Sure, if you want to destroy all of the changes made to the
database in that transaction and thorough
32 matches
Mail list logo
