So there it is, at long last, the final 1.0.0 release of prefix! It’s on its way into the debian repository (targetting sid, in testing in 10 days) and available on pgfoundry to.
In order to make it clear that I intend to maintain this version, the number has 3 digits rather than 2… which is also what PostgreSQL users will expect.
The only last minute change is that you can now use the first version of the two following rather than the second one:
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 :)
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!
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.
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.