<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Others gave lots of good feedback, but let me chime in.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

* I didn't know about pgpool. It looks like it may come in handy if there connections become sluggish or simply impossible due to too many users. I will definitely keep this under my hat, although I understand it is a UNIX-only solution.<br></blockquote><div><br></div><div>Essential in a multiuser environment.<br> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
* About usage being mostly read: this will be true for most "pure GIS" tasks (mostly intersecting), but I find that (from experience), we usually end up with a lot of intermediary tables for our analyses (new tables for the most part, not new columns).<br></blockquote><div><br></div><div>New tables and intersections or process that go somewhat like Geoprocessing in ArcGIS (execute step 1, store the result in A, process B with A, write in C, process C with D to get E) means that you will have a lot of IO going on. If you have 10 students crunching numbers in PostGIS writing new results together, this will mean significant IO. Get fast disks. 15k RPM, 10k RPM or SSD. This can get your price tag to get a bit high quickly.<br><br></div><div>Mind that you can tune PostgreSQL to store you indexes in faster disks, allowing you to store the bulk of your data on slower disks. If you have the money, go with the fastest disks anywhere you can.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
* About MS vs. Linux based servers: same here, as long as the IT deal with it, I would be inclined to say this is not an issue (or at least this is not mine!). I agree though that, for a personal use (i.e. computer based in my lab), Linux systems are much easier to deal with (all my computers actually run Debian). But that's one the reasons I want a server in the center: it would come with a sysadmin who would deal with the hassle... I was thinking more in terms of possibilities here (remote access, linking PostGIS with R, etc.); in other words, do we lose anything *as a user* with a MS server?<br></blockquote><div><br></div><div>There are some articles (sorry, forgot where) that clearly state that PostgreSQL performs much better in linux systems. Looks like not so much these days. Check:<br><br><a href="http://stackoverflow.com/questions/8368924/postgresql-performance-on-windows-using-latest-versions">http://stackoverflow.com/questions/8368924/postgresql-performance-on-windows-using-latest-versions</a><br><br></div><div>The good parts is that it's much easier, at least for me to admin services and everything PostgreSQL need on linux. It's easier to install properly, easier to configure it properly, amongst others. This is a personal preference. If you can, go with linux (IMHO).<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Finally, may I ask you about your own setup (number of users, typical use cases, hardware specs, etc.)? It would probably help me.<br></blockquote><div><br></div><div>I have a company with 12 concurrent QGIS users, editing around 50.000km2 of land use coverage in 1:5000 scale. It has a lot of detail. We do more editing then processing, but there are some heavy stuff, such as "complete feature" tool from QGIS, which in BIG geometries can take some time.<br><br></div><div>My setup is:<br><br></div><div>Bare metal machine with ESXI;<br></div><div>PostgreSQL machine with 8Gb RAM;<br></div><div>2x processors quad-core;<br></div><div>PostgreSQL tuned for fast reads, large, large cache;<br></div><div>pgPool;<br></div><div>disks: 2 7.200RPM disks (I'm not at the office and I don't really remember this, but I think this is 7.200rpm) - with RAID 1.<br></div><div><br></div><div>Data is spread in two databases - meaning two non contiguous projects. Each table has around 25k km2.<br><br></div><div>We backup each database to a separate dump and upload it to rackspace.</div></div></div></div>