Wednesday, January 06. 2010

Ah a new year, a new PostgreSQL release in the works. Beware -- this post is a bit sappy as we are going to highlight those that have made our lives and lives of many a little easier.

These are people we consider the most important because they provide the first impression that newcomers get
when first starting off with PostgreSQL. The newcomer that quickly walks out the door unimpressed, is the easy sale you've lost. Make your pitch short and sweet.

As always Hubert does a really good job of taste testing the new treats
in the oven and detailing how cool they are. I highly suggest his posts if people have not read them already or are
looking at PostgreSQL for the first time.
You can catch his Waiting for PostgreSQL 8.5 series which is in progress.
Surely gives us a list of things to test drive.

Then there are those that document, the volumes of PostgreSQL documentation which are just great, up to date and rich with content. Probably too many of these
people to call out, and sadly we don't know them by name.

Of course its not just enough to announce releases, document them and talk about them, you must make it really easy for people to try them out.
If people have to compile stuff, especially windows users, forget about it.
You won't hear complaints, you won't hear whispers, you'll hear dust blowing. The biggest audience you have is the one you just lost
because you didn't make it easy for them to try your stuff. The apple hit me on the head one day when a very dear friend said to me
and here is a slight paraphrase.
You don't actually expect me to compile this myself do you? How much time do you think I have? It is not about you, it is about me..
This was especially surprising coming from a guy I always thought of as selfless.
This I realized is the biggest problem with many open source projects, that they are lost in the flawed mentality that its about scratching
their own itch and the rest will come. It is not. Always concentrating on your own itch and scratching it is a sure way of guaranteeing that no one will scratch your itch for you.
Think of it like a pool game. Do you target the aim at the ball you are trying to hit, or balls near by that will knock down the others.
So in short don't be a complete wuss that people can walk all over, but look past your nose and choose your balls wisely; make sure all your balls are not
focused on software development.

So in the spirit of scratching someone else's itch, We would also like to thank greatly the efforts of:

Devrim for his work with the PostgreSQL Yum repository
which has personally made our lives a lot easier.

To all those countless testers, documenters, other packagers, and bloggers that make PostgreSQL a wow its fast, wow its cool, and I don't see any bugs experience.

We haven't started to play with PostgreSQL 8.5 yet but plan to in the next month or two. Surprisingly we are more interested in the smaller things than the big Hot-Standby feature everyone is talking about.
The things we are most excited about trying out so far

Grant All this is just a great usability feature. Its one of the
reasons why new users just run everything under postgres account or whine about how MySQL security is so much easier, cause its too damn much effort to secure things correctly in PostgreSQL.
It also comes close and perhaps better than feature of SQL Server that has built-in data reader/data writer roles you can assign to users/groups to give them the
rights and all rights in future to created tables.

Exclusion constraints. I'm really hoping this
will help serve a somehwat nagging problem that we have that you can't use constraint exclusion inheritance benefits to partition data by geometric space. Well we'll see. It is a dream.

Named function arguments, this is one of the reasons I love VB as a language, because VB has named arguments and why I find C# and all those C like knock-offs
frustrating to work with at times because they lack these nuggets of syntactic sugar.

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.

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.

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++.

E-Mail addresses will not be displayed and will only be used for E-Mail notifications.

To prevent automated Bots from commentspamming, please enter the string you see in the image below in the appropriate input box. Your comment will only be submitted if the strings match. Please ensure that your browser supports and accepts cookies, or your comment cannot be verified correctly.Enter the string from the spam-prevention image above: