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 kind of controller
[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
[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
[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:
[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
[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
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
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 opinions
[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
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
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 system
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
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 is
[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,
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
better
[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,
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 is
[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
[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
[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. I'd never
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 single object, the
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.
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
[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 databases
[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
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
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
27 matches
Mail list logo
