<br>You can make multiple disks act like one using a method called striping.<br><br>Here is the first link I googled.  Apparently it will increase performance as well...<br><br><a href="http://insights.oetiker.ch/linux/raidoptimization/">http://insights.oetiker.ch/linux/raidoptimization/</a><br>
<br><br><div class="gmail_quote">On Tue, Apr 6, 2010 at 10:58 AM, Brian Modra <span dir="ltr"><<a href="mailto:brian@zwartberg.com">brian@zwartberg.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">On 06/04/2010, P Kishor <<a href="mailto:punk.kish@gmail.com">punk.kish@gmail.com</a>> wrote:<br>
> I asked this question yesterday, and received a very helpful pointer<br>
> from Ben Madin re. TABLESPACES. As noted in my reply in that thread, I<br>
> am also investigating the possibility of splitting a single table<br>
> across multiple disks.<br>
><br>
> However, I am going to post this question in a different way in this new<br>
> thread.<br>
><br>
> Suppose I have a table FOO0 that stores info about every state in the<br>
> union. I know that some of these states will have mongo number of<br>
> rows, but I don't have to build all the states immediately. So, I<br>
> start with a few states' worth data, putting it in the default<br>
> /usr/local/pgsql/data location.<br>
><br>
> Then I start outgrowing that disk, and need to add another state, so I<br>
> add another disk, create a new tablespace, and create a new table<br>
> called FOO1 in this new tablespace. Then I can store the new states in<br>
> FOO1. As long as I break up my table into FOO0, FOO1, FOO2, and so on,<br>
> I can store each FOOn in a new tablespace. And, as long as I ensure<br>
> that each FOOn table contains a geographically consistent spatial<br>
> extent, I can build logic in my application to query the correct<br>
> table.<br>
><br>
> So, lets say 0 lon to -10 lon data are stored in FOO0, and -10 lon to<br>
> -20 lon in FOO1, then if the user requests data for -5 lon to -15 lon,<br>
> I will have to query both FOO0 and FOO1.<br>
<br>
</div>If you split the data by lat-long extents, then you will need to also<br>
create duplicates of some of the data... anything that intersects the<br>
boundary must be duplicated...<br>
<br>
I assume you have a table with state boundaries in it?<br>
You could use this as an "index" to the table name. Then store a state<br>
per table...<br>
<br>
So when you do a spatial query, you first use the extent of the query<br>
to find which state(s) are withing/intersecting/contain the query<br>
area. Then you can generate one or more spatial queries to the tables<br>
containing the states data.<br>
<div class="im"><br>
> More work for me, but it is doable, no? Any insights on how to handle<br>
> something like this?<br>
<br>
</div>yes<br>
<div class="im"><br>
> A corollary question -- are their any speed advantages to actually<br>
> creating multiple PostGIS instances, perhaps even splitting them<br>
> across multiple machines? Of course, it is going to be a pain in the<br>
> ass for me to maintain more than one instance of PostGres/PostGIS, so<br>
> I am not thrilled at that possibility. I'd rather have a single<br>
> instance just be managing data across multiple locations as required.<br>
<br>
</div>Using multiple machines means that parallel retrievals are possible.<br>
It has to make it faster.<br>
... but your idea of splitting data geographically probably makes this<br>
unlikely to happen in the majority of queries.<br>
<br>
Rather than split the data geographically, is there some property in<br>
the tables that can be used to split it up... so that certain rows<br>
(based on this key) go to different tables?<br>
This may result in a better performance benefit, because a single<br>
spatial query will hit multiple databases, returning rows in parallel.<br>
<br>
But then again, all this depends on how you gather your data for a<br>
query... to make what I just described work, you'd have to execute<br>
multiple queries at once, i.e. multi-threading.<br>
<br>
><br>
><br>
> --<br>
<div class="im">> Puneet Kishor <a href="http://www.punkish.org" target="_blank">http://www.punkish.org</a><br>
> Carbon Model <a href="http://carbonmodel.org" target="_blank">http://carbonmodel.org</a><br>
> Charter Member, Open Source Geospatial Foundation <a href="http://www.osgeo.org" target="_blank">http://www.osgeo.org</a><br>
> Science Commons Fellow, <a href="http://sciencecommons.org/about/whoweare/kishor" target="_blank">http://sciencecommons.org/about/whoweare/kishor</a><br>
> Nelson Institute, UW-Madison <a href="http://www.nelson.wisc.edu" target="_blank">http://www.nelson.wisc.edu</a><br>
> -----------------------------------------------------------------------<br>
> Assertions are politics; backing up assertions with evidence is science<br>
> =======================================================================<br>
> _______________________________________________<br>
> postgis-users mailing list<br>
> <a href="mailto:postgis-users@postgis.refractions.net">postgis-users@postgis.refractions.net</a><br>
> <a href="http://postgis.refractions.net/mailman/listinfo/postgis-users" target="_blank">http://postgis.refractions.net/mailman/listinfo/postgis-users</a><br>
><br>
<br>
<br>
</div><font color="#888888">--<br>
Brian Modra   Land line: +27 23 5411 462<br>
Mobile: +27 79 69 77 082<br>
5 Jan Louw Str, Prince Albert, 6930<br>
Postal: P.O. Box 2, Prince Albert 6930<br>
South Africa<br>
<a href="http://www.zwartberg.com/" target="_blank">http://www.zwartberg.com/</a><br>
</font><div><div></div><div class="h5">_______________________________________________<br>
postgis-users mailing list<br>
<a href="mailto:postgis-users@postgis.refractions.net">postgis-users@postgis.refractions.net</a><br>
<a href="http://postgis.refractions.net/mailman/listinfo/postgis-users" target="_blank">http://postgis.refractions.net/mailman/listinfo/postgis-users</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Cheers!<br>Rick<br><br>