On Wed, 30 May 2007, Jonah H. Harris wrote:
On 5/29/07, Luke Lonergan <[EMAIL PROTECTED]> wrote:
AFAIK you can't RAID1 more than two drives, so the above doesn't make
sense
to me.
Yeah, I've never seen a way to RAID-1 more than 2 drives either. It
would have to be his first one:
D1 + D2
On 5/29/07, Luke Lonergan <[EMAIL PROTECTED]> wrote:
AFAIK you can't RAID1 more than two drives, so the above doesn't make sense
to me.
Yeah, I've never seen a way to RAID-1 more than 2 drives either. It
would have to be his first one:
D1 + D2 = MD0 (RAID 1)
D3 + D4 = MD1 ...
D5 + D6 = MD2 ..
On Tue, 2007-05-29 at 21:43 +0100, Dave Page wrote:
> Cliff, Jason or Rob era? Could be important...
Cliff and Jason.
Rob is in my Ozzy collection ;-)
--
Groeten,
Joost Kraaijeveld
Askesis B.V.
Molukkenstraat 14
6524NB Nijmegen
tel: 024-3888063 / 06-51855277
fax: 024-3608416
web: www.askesis.nl
Stephen,
On 5/29/07 8:31 PM, "Stephen Frost" <[EMAIL PROTECTED]> wrote:
> It's just more copies of the same data if it's really a RAID1, for the
> extra, extra paranoid. Basically, in the example above, I'd read it as
> "D1, D2, D5 have identical data on them".
In that case, I'd say it's a wast
* Luke Lonergan ([EMAIL PROTECTED]) wrote:
> Hi Rajesh,
>
> On 5/29/07 7:18 PM, "Rajesh Kumar Mallah" <[EMAIL PROTECTED]> wrote:
>
> > D1 raid1 D2 raid1 D5 --> MD0
> > D3 raid1 D4 raid1 D6 --> MD1
> > MD0 raid0 MD1 --> MDF (final)
>
> AFAIK you can't RAID1 more than two drives, so the above d
Hi Rajesh,
On 5/29/07 7:18 PM, "Rajesh Kumar Mallah" <[EMAIL PROTECTED]> wrote:
> D1 raid1 D2 raid1 D5 --> MD0
> D3 raid1 D4 raid1 D6 --> MD1
> MD0 raid0 MD1 --> MDF (final)
AFAIK you can't RAID1 more than two drives, so the above doesn't make sense
to me.
- Luke
-
Klint Gore <[EMAIL PROTECTED]> writes:
> On Tue, 29 May 2007 17:16:57 -0700, "Tyrrill, Ed" <[EMAIL PROTECTED]> wrote:
>> mdsdb=# explain analyze select backupobjects.record_id from
>> backupobjects left outer join backup_location using(record_id) where
>> backup_id = 1071;
> Why are you using left
On 5/30/07, Luke Lonergan <[EMAIL PROTECTED]> wrote:
Stripe of mirrors is preferred to mirror of stripes for the best balance of
protection and performance.
nooo! i am not aksing raid10 vs raid01 . I am considering stripe of
mirrors only.
the question is how are more number of disks supposed to
On Tue, 29 May 2007 17:16:57 -0700, "Tyrrill, Ed" <[EMAIL PROTECTED]> wrote:
> mdsdb=# explain analyze select backupobjects.record_id from
> backupobjects left outer join backup_location using(record_id) where
> backup_id = 1071;
[...]
>
> Here are the two tables in the query:
>
> mdsdb=# \d back
On May 29, 2007, at 19:16 , Tyrrill, Ed wrote:
-
Hash Join (cost=361299.50..1054312.92 rows=34805 width=8) (actual
time=1446.861..368723.597 rows=2789 loops=1)
Hash Cond: ("outer".record_id = "inner".record_id)
-> Seq Scan on backupobjects (cost=0.00..429929.79 rows=13136779
width
On Fri, 2007-05-25 at 20:16 +0200, Arnau wrote:
The point I'm worried is performance. Do you think the performance
would be better executing exactly the same queries only adding an extra
column to all the tables e.g. customer_id, than open a connection to the
only one customers DB and execut
Hi All,
I have a very slow left outer join that speeds up by more then 1000
times when I turn set enable_seqscan=off. This is not the query I
actually do in my application, but is a simplified one that singles out
the part that is really slow. All of the columns involved in the query
have indexe
On Fri, 2007-05-25 at 20:16 +0200, Arnau wrote:
>The point I'm worried is performance. Do you think the performance
> would be better executing exactly the same queries only adding an extra
> column to all the tables e.g. customer_id, than open a connection to the
> only one customers DB and
Stripe of mirrors is preferred to mirror of stripes for the best balance of
protection and performance.
In the stripe of mirrors you can lose up to half of the disks and still be
operational. In the mirror of stripes, the most you could lose is two
drives. The performance of the two should be si
hi,
this is not really postgresql specific, but any help is appreciated.
i have read more spindles the better it is for IO performance.
suppose i have 8 drives , should a stripe (raid0) be created on
2 mirrors (raid1) of 4 drives each OR should a stripe on 4 mirrors
of 2 drives each be created
Dave Page wrote:
and lots of entries looking just like this ( 0 % CPU, > 500 secs).
There are no other connections to the database and the machine does not
do anything else than me typing this e-mail and playing Metallica MP3's.
Cliff, Jason or Rob era? Could be important...
Well Metallica
Joost Kraaijeveld wrote:
> Hi
>
> I am currently running a vacuum analyse through PgAdmin on a PostgreSQL
> 8.1.9 database that takes forever without doing anything: no
> (noticeable) disk activity or (noticeable) CPU activity.
>
> The mesage tab in PgAdmin says:
>
> ...
> Detail: 0 index page
Michal Szymanski wrote:
> There is another strange thing. We have two versions of our test
> >>environment one with production DB copy and second genereated with
> >>minimal data set and it is odd that update presented above on copy of
> >>production is executing 170ms but on small DB it executin
On Tue, 2007-05-29 at 19:16 +0200, PFC wrote:
>
> > Could this be because of my Cost-Based Vacuum Delay settings ?
>
> Yeah. It is supposed to slow down VACUUM so it doesn't kill your
> server,
> but it is not aware of the load. It will also slow it down if there is no
> load. That is
Could this be because of my Cost-Based Vacuum Delay settings ?
Yeah. It is supposed to slow down VACUUM so it doesn't kill your server,
but it is not aware of the load. It will also slow it down if there is no
load. That is its purpose after all ;)
If you want fast vacuum, issue
Hi
I am currently running a vacuum analyse through PgAdmin on a PostgreSQL
8.1.9 database that takes forever without doing anything: no
(noticeable) disk activity or (noticeable) CPU activity.
The mesage tab in PgAdmin says:
...
Detail: 0 index pages have been deleted, 0 are currently reusable
On 5/26/07, Peter T. Breuer <[EMAIL PROTECTED]> wrote:
"Also sprach Tom Lane:"
> "Peter T. Breuer" <[EMAIL PROTECTED]> writes:
> > But can I prepare a DECLARE x BINARY CURSOR FOR SELECT ... statement?
> > The manual seems to say no.
>
> No, you just prepare the SELECT. At the protocol level, DE
On 5/28/07, Dave Cramer <[EMAIL PROTECTED]> wrote:
Since PITR has to enable archiving does this not increase the amount
of disk I/O required ?
I've set up warm standbys on a few servers (some of them quite
busy!)...the additional load is virtually unmeasurable. I usually
don't copy the files l
I assume you meant topic_id, post_id. :)
Um, yes ;)
The problem with your proposal is that it does nothing to ensure that
posts for a topic stay together as soon as the table is large enough
that you can't sort it in a single pass. If you've got a long-running
thread, it's still
On May 27, 2007, at 12:34 PM, PFC wrote:
On Sun, 27 May 2007 17:53:38 +0200, Jim C. Nasby
<[EMAIL PROTECTED]> wrote:
On Tue, May 22, 2007 at 09:29:00AM +0200, PFC wrote:
This does not run a complete sort on the table. It would be
about as
fast as your seq scan disk throughput. Obviously, t
25 matches
Mail list logo
