We got back from PostgreSQL Conf 2015 which was in New York City. It's probably the most educational conference we've been to in a while and mostly because we stayed thru the whole conference.
One of the key take aways from the conference was Magnus Hagander's 9.5 showcase of features slides at http://www.hagander.net/talks/postgresql95.pdf. There are 2 things I am looking for which are along the lines of parallelization and the 3rd I'm not sure about is of much benefit but could be.
Inheritance support for Foreign Tables (aka sharding with FDWs)
The thing I was most excited about was Foreign Table inheritance (and BTW you can add check constraints to Foreign tables) which means you can use the constraint exclusion feature of PostgreSQL
to query across federated PostgreSQL servers. The thing that excited me about this, is I had a perfect use case I was itching to try -- which I have on my list. The PostGIS Tiger geocoder utilizes
an inheritance hierarchy to partition tables. When I took on maintainance of the geocoder and changed it to use a table inheritance instead of single table structure, I was not so much concerned about speed as much as being able to easily spit out a backup of a set of states to create a smaller database I could hand-off to a user or specific client. Since it is already naturally sharded and has that built-in its query logic, it would seem a perfect fit to test if parallelization could work in this fashion and improve speed for similar setups. Michael Paquier has a simple example of this feature in PostgreSQL 9.5 feature highlight: Scale-out with Foreign Tables now part of Inheritance Trees
Parallel sequential scans
This one isn't quite in yet, but is in the queue of likely candidates. So we don't have parallalization for all query methods, but this is the first step to getting there and one that doesn't require any changes on your part to take advantage of.
GiST index only scan
Big gotcha here is that it is only currently supported for built in PostgreSQL box and point classes. The bigger question is, is it really worthwhile to implement in PostGIS 2.2 for PostGIS types.
I have to say this was a bit of a yawn for me, but I point it out because it was the only time Magnus mentioned PostGIS - "PostGIS folks in crowd, can PostGIS use this?".
I doubt it will provide much benefit since the GisT we have just contains the box and requires a RECHECK anyway. Conceivably it could be useful for counting points or as a very fuzzy estimate of count of objects in a window, but that's all I can think it could be useful for. How much effort to build in the logic in PostGIS 2.2 I don't know. I leave that as an excercise for someone smarter than me.