What if you could turn
thousands of lines of code into
simple queries?

It seems like debian developers are back from annual conference and holiday, so they have had a look at the NEW queue and processed the packages in there. Two of them were mines and waiting to get in unstable, hstore-new and preprepare. Time to do some bug fixing already, as hstore-new packaging is using a bash’ism I shouldn’t rely on (or so the debian buildfarm is telling me) and for preprepare I was waiting for inclusion before to go improving the GUC management, stealing some code from Selena’s pgGearman :)


I wrote a book!


At long last, here it is. With binary versions both for postgresal-8.3 and postgresal-8.4! Unfortunately my other packaging efforts are still waiting on the NEW queue, but I hope to soon see hstore-new and preprepare enter debian too. Anyway, the plan for prefix is to now wait something like 2 weeks, then, baring showstopper bugs, release the 1.0 final version. If you have a use for it, now is the good time for testing it!


prefix 1.0~rc2-1

I’ve been having problem with building both postgresql-8.3-prefix and postgresql-8.4-prefix debian packages from the same source package, and fixing the packaging issue forced me into modifying the main prefix Makefile. So while reaching rc2, I tried to think about missing pieces easy to add this late in the game: and there’s one, that’s a function length(prefix_range), so that you don’t have to cast to text no more in the following wildspread query:


At long last, after millions and millions of queries just here at work and some more in other places, the prefix project is reaching 1.0 milestone. The release candidate is getting uploaded into debian at the moment of this writing, and available at the following place: prefix-1.0~rc1.tar.gz. If you have any use for it (as some VoIP companies have already), please consider testing it, in order for me to release a shiny 1.


I can’t really compare PgCon 2009 with previous years versions, last time I enjoyed the event it was in 2006, in Toronto. But still I found the experience to be a great one, and I hope I’ll be there next year too! I’ve met a lot of known people in the community, some of them I already had the chance to run into at Toronto or Prato, but this was the first time I got to talk to many of them about interresting projects and ideas.


On the performance mailing list, a recent thread drew my attention. It devired to be about using a connection pool software and prepared statements in order to increase scalability of PostgreSQL when confronted to a lot of concurrent clients all doing simple select queries. The advantage of the pooler is to reduce the number of backends needed to serve the queries, thus reducing PostgreSQL internal bookkeeping. Of course, my choice of software here is clear: PgBouncer is an excellent top grade solution, performs real well (it won’t parse queries), reliable, flexible.

Dimitri Fontaine

PostgreSQL Major Contributor

Open Source Software Engineer

France