> [EMAIL PROTECTED] wrote:
>
>>
>>What you are missing is that the RAID is dealing with the multiple drives
>>as one drive. Two operations have to happen serially,
>>
>
> You're kidding or vastly underestimating raid controllers. The average
> db access is well served with a single block of data, s
> Dear anonymous,
>
> This is really making me tired, and still OT. May anybody interested
> read the document you're citing abusively, or believe you that storage
> controllers are only capable of one command at a time or not.
I would say this is totally off topic except that it does present opin
Dear anonymous,
This is really making me tired, and still OT. May anybody interested
read the document you're citing abusively, or believe you that storage
controllers are only capable of one command at a time or not.
Regards,
Andreas
---(end of broadcast)---
> [EMAIL PROTECTED] wrote:
>
>>>[EMAIL PROTECTED] wrote:
>>>
>>>
>>>
What you are missing is that the RAID is dealing with the multiple
drives
as one drive. Two operations have to happen serially,
>>>You're kidding or vastly underestimating raid controllers. The average
[EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] wrote:
What you are missing is that the RAID is dealing with the multiple drives
as one drive. Two operations have to happen serially,
You're kidding or vastly underestimating raid controllers. The average
db access is well served with a single
[EMAIL PROTECTED] wrote:
What you are missing is that the RAID is dealing with the multiple drives
as one drive. Two operations have to happen serially,
You're kidding or vastly underestimating raid controllers. The average
db access is well served with a single block of data, stored on a single
> [EMAIL PROTECTED] wrote:
>
>>
>>As for IDE RAID, IDE RAID is an awesome idea. SCSI disks are just too
>>expensive. Infortrend has a cool IDE to SCSI or Fibre RAID system that
>>rocks.
>>
>>
>
> Obviously, you're caught by those marketing geeks. You're taking
> bandwidth (MB/s)as performance index
[EMAIL PROTECTED] wrote:
As for IDE RAID, IDE RAID is an awesome idea. SCSI disks are just too
expensive. Infortrend has a cool IDE to SCSI or Fibre RAID system that
rocks.
Obviously, you're caught by those marketing geeks. You're taking
bandwidth (MB/s)as performance index, which is irrelevant
On Fri, 2004-05-28 at 08:15, [EMAIL PROTECTED] wrote:
> > [EMAIL PROTECTED] wrote:
> >
> >>You are absolutely wrong on all accounts here. A RAID5 system is slower
> >>than a single spindle as it is only as fast as the slowest disk in the
> >>stripe and the overhead of the RAID.
> >>
> > Huh, what k
Josh Berkus wrote:
> The whole point of tablespaces is to
> allow placing individual tables and indexes
> on seperate volumes.
That was one reason. I seem to recall several more:
* Putting data on cost appropriate media
Mentioned previously in this thread
* Balancing I/O across spindles
Also menti
[EMAIL PROTECTED] wrote:
A single postgresql process may not see much benefit, because it does not
do background I/O,
Not yet, I believe that in 7.5 there is a component that do it.
Am I wrong ?
Regards
Gaetano Mendola
---(end of broadcast)---
TIP 8
> One other huge advantage that tablespaces will bring, it the ability to
> place
> data based on "cost" ie, you can put your 10 most used tables on fast disk
> (or perhaps solid state devices), and move the seldom used data off onto
> the
> slower (lower cost) disks/storage array.
Great idea.
-
On May 27, 2004 01:38 pm, [EMAIL PROTECTED] wrote:
> > [EMAIL PROTECTED] wrote:
> >>As you can see, it takes a LOT longer. That's because the disk has to do
> >> a
> >>lot more work, the hardware data path has to carry twice as much data,
> >> and
> >>you have to manage multiple accesses to a singl
> [EMAIL PROTECTED] wrote:
>
>>You are absolutely wrong on all accounts here. A RAID5 system is slower
>>than a single spindle as it is only as fast as the slowest disk in the
>>stripe and the overhead of the RAID.
>>
> Huh, what kind of controller do you use... Sounds like some "value" IDE
> one.
> [EMAIL PROTECTED] wrote:
>
>>
>>As you can see, it takes a LOT longer. That's because the disk has to do
>> a
>>lot more work, the hardware data path has to carry twice as much data,
>> and
>>you have to manage multiple accesses to a single object, the disk.
>>
>>It doesn't take much imagination
[EMAIL PROTECTED] wrote:
As you can see, it takes a LOT longer. That's because the disk has to do a
lot more work, the hardware data path has to carry twice as much data, and
you have to manage multiple accesses to a single object, the disk.
It doesn't take much imagination to see what this would m
> "Mohawksoft":
>
>> I forgot to specify that tablepaces should be on separate volumes.
>> (sorry)
>> If all they have is one volume, no worries, but instructing the use of
>> alternate volumes for system and data will improve performance by
>> separating WAL and data operations.
>
> ... and the pl
> [EMAIL PROTECTED] wrote:
>
>>>James Robinson wrote:
>>>
>>>
>>>
>Users are primarily, if not stupid, ignorant. They will read the
>absolute
>minimum needed to achieve a goal and little else. I say this with the
>utmost respect, because I and probably everyone else on this group is
> In the age of inexpensive RAID, tablespaces have more or less lost their
> relevance regarding performance. pgsql's philosophy respects this by
> leaving the storage work up to the OS and disk subsystem. Even having
> the xlog on a different spindle won't help too much; you'll probably be
> bette
[EMAIL PROTECTED] wrote:
James Robinson wrote:
Users are primarily, if not stupid, ignorant. They will read the
absolute
minimum needed to achieve a goal and little else. I say this with the
utmost respect, because I and probably everyone else on this group is
guilty of the same thing. So, the
"Mohawksoft":
> I forgot to specify that tablepaces should be on separate volumes. (sorry)
> If all they have is one volume, no worries, but instructing the use of
> alternate volumes for system and data will improve performance by
> separating WAL and data operations.
... and the place for this
> James Robinson wrote:
>
>>>
>>>
>>> Users are primarily, if not stupid, ignorant. They will read the
>>> absolute
>>> minimum needed to achieve a goal and little else. I say this with the
>>> utmost respect, because I and probably everyone else on this group is
>>> guilty of the same thing. So, t
> Yes, that is generally the case (prefer pg_xlog on separate spindle),
> but no
> need to *forcibly* overcomplicate things if the box has only one
> spindle,
> or if they have only one single RAID'd partition configured. We should
> continue to err on the side of keeping the path to a functional s
James Robinson wrote:
Users are primarily, if not stupid, ignorant. They will read the
absolute
minimum needed to achieve a goal and little else. I say this with the
utmost respect, because I and probably everyone else on this group is
guilty of the same thing. So, the "preferred" installation pr
On May 26, 2004, at 7:14 PM, [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] writes:
First, we keep the standard PostgreSQL directory the way it has
always
been with template0, template1, pg_xlog, pg_clog, etc. in the same
place.
We can refer to this as the "system" directory. This makes sense
because
BTW: Is there a public spec on what will be tablespace compatible and how?
For instance: will is be possible to create a table on a separate
tablespace than the DB? Will it be possible to create an index on a
separate tablespace than the table?
(Since Gavin hasn't replied yet)
1. There are two defa
> [EMAIL PROTECTED] writes:
>> First, we keep the standard PostgreSQL directory the way it has always
>> been with template0, template1, pg_xlog, pg_clog, etc. in the same
>> place.
>> We can refer to this as the "system" directory. This makes sense because
>> all the system level stuff is there. U
[EMAIL PROTECTED] writes:
> First, we keep the standard PostgreSQL directory the way it has always
> been with template0, template1, pg_xlog, pg_clog, etc. in the same place.
> We can refer to this as the "system" directory. This makes sense because
> all the system level stuff is there. User datab
Now that it looks like tablespaces will become a practical reality, I want
to suggest some changes in documented procedure and preferred setup. The
reason why I suggest these changes is to enlighten new PostgreSQL users to
the new features and, perhaps, make a more enterprise-familiar environment
f
29 matches
Mail list logo
