Wednesday, January 06. 2010Looking forward to PostgreSQL 8.5Printer FriendlyRecommended Books: PostGIS In Action PostgreSQL 8.4 Official The SQL Language PostgreSQL 8.4 Server Administration
Comments
Display comments as
(Linear | Threaded)
"...problem that we have that you can't use constraint exclusion inheritance benefits to partition data by geometric space"
Exclusion Constraints have nothing to do with constraint_exclusion. That may be unfortunate naming. Why does constraint_exclusion not allow you to partition data by geometric space?
Jeff,
I didn't think they did. I guess I was thinking more along the idea that it would give me ideas :) If you were to put a constraint in for geometric data you would have a constraint that sort of bounds the region in the table with something like && BOX(....) Most PostGIS relationship function have the && .. built in to utilize indexes and also it is common practice when pulling data for a map to do a && ... box region -most map servers do that automagically. If the planner could recognize that if a box does not overlap the table constrained box, then there would be no reason to search the table, and that I would suspect be a big performance boost for very large spatial dbs. But && is not a range constraint (well it sort of is), but its not seen as such by the planner. So although you can in theory do this, it does you no good when doing queries against an inherited table hierarchy because it still scans the tree. Well I haven't tried it in a while so I should give it a try again before I open my mouth :). So general work around is that you still partition by space using some btree code like region_name and tack these on to your queries. This is generally what we do.
Don't take this as a total rant, but...
I'd like to NOT thank the people who decided the "one-click installer" (that requires lots of clicks, doesn't work on correctly secured Win7/WS2008R2 and is unbearable for administrators to use) is a lot better than the old MSI based thing (which has NONE of the aforementioned problems). It's like telling Debian users to install Pgsql from tar packages and run random scripts to rape the package system to think it's installed. I'd like also to NOT thank you two for your strange page where you complain about the problems compiling PostGIS etc on Windows. I find it strange that one would complain about a platform not being like Linux with myriads of compiling thingies. Platforms are different, which should be quite obvious to anyone in the SW industry. And I really don't understand why you'd want to compile PostGIS with mingw. You know, I took the sources of PostGIS, GEOS and PROJ (never ever having seen them before) and within 15 minutes I had a Visual Studio solution compiling the whole thing, the resulting binary is smaller than with mingw and even works slightly faster. So is the problem with Windows or the people using wrong compilation tools? And a hint: Visual C++ compiler is free. But anyway, I'd like to thank you for PostGIS, since it's a wonderful tool and I really couldn't live without it.
Sami,
Did you report these problems. I haven't run into the issues you described running on my windows 7 or windows 2008 boxes even with windows firewall and virus software installes. Could be a virus scanner conflict problem. Right now for Windows PostGIS really only supported compiled under MingW. This is on our todo list to change , but we have higher priorities at the moment. For the most part people don't need to compile PostGIS under Windows anyway since we do the compiling. Its always better to have a vocal critical user than a silent frustrated one, so we welcome your rants :). I would be interested in your PostGIS compile instructions and how the performance is for you though (if you would like to document them on the PostGIS wiki -- we would be very delighted :). http://trac.osgeo.org/postgis Which version were you compiling? Mateusz did do some cleanup to make it compile under VC++ http://mateusz.loskot.net/2009/03/29/building-postgis-using-visual-cpp/ so the ability you can compile at all is probably of great thanks to him , but sadly he didn't have time to maintain it, and we are still getting our feet wet with maintenance so not quite ready to rock the boat yet. VC++ has never been supported for PostGIS so didn't want to risk it for current go around without extensive testing. We are taking over the task of building the PostGIS installers so we are still feeling our way thru the process. Eventually we would like to have it compiled in VC++. Anyrate any support you can provide is very welcome :).
Sami, you mean 15 minutes? Tell me first when you did that. I assume it was after March 2009. Previously, PostGIS did not compile using Visual C++ due to use of incompatible features not available in C++ implementation from Visual C++.
Here is the story: http://mateusz.loskot.net/2009/03/29/building-postgis-using-visual-cpp/ Also, check number of commits to PostGIS. Mateusz |
Entry's LinksQuicksearchCalendar
Categories
Blog Administration |
Tracked: Jan 06, 13:53
Tracked: Jan 15, 13:34