I wonder if there are test results
> published on this?
I haven't seen any, I am just recalling a previous thread on one of the PostgreSQL lists that
mentioned that manually partitioning data is a complicated process. Spreading the I/O load and db
tuple growth across all of these drives will continue to be a challenge. All of these is better
left to a raid array which handles all of this for you.
> > It seems and it is hard to balance tuple growth
> > evenly across all of the drives.
>
> Is this done with
> create tablespace? The doc shows the create tablespace directory
> as singular. How would you get a table to cross drives otherwise?
> Maybe you are not refering to tuple growth in one table?
Yes, other than creating a tablespace, you can use symbolic links that point to data that you
moved to other drives. I do not believe that it is possible to split a table across multiple
partitions without using table partitioning in your logical data model. However a raid array
should spread your data across all of the drives evenly without any creativity on our part.
> My idea (from standard ora practices) was to split table and indexes on that
> table across drives with create tablespace, standard ora practice.
That is a very enteresting feature with oracle. I haven't seen any automatic "splitting"
functionality in PostgreSQL that would do table and index partitioning for you.
However, if you create table partitions in your logical data model, you could move those
partitions to different drives. Also, you could manually create partial indexes for each of the
table partitions that could also be moved to different drives. But all of this would have to
modeled and constructed on your part.
> > Also most of your data writes are on one table, then you are
> > limited to the i/o bandwidth of one drive anyway.
>
> One table? What table are you refering to? Novice here...
My mistake, I meant, "If most of you data writes are on one of your tables, then you are limited
to the i/o bandwidth of the drive that the table is physically located on".
Regards,
Richard Broersma Jr.
