PostGIS specific dynamic background workers

[robe]

Snooping on pgadvocacy ​http://www.postgresql.org/message-id/CAFj8pRA8+J17PxmmL1B8b-4bfbHvpQPcp7g7rG7Skune=BuY8Q@mail.gmail.com got me thinking.

I admit to not having looked at the background API in PostgreSQL 9.4+. So this is more of a placeholder to investigate, see how useful it is, and if useful add to PostGIS 2.2 additional extensions only installed for those folks running PostgreSQL 9.4+.

Areas I see where background workers might be useful are in obviously long running processes where running in a single transaction is bloody slow and the work needs to be broken up into separate runs.

1) raster processing 2) topology processing 3) tiger geocoder processing

I suspect we'd probably need separate background workers for each tailored to the unique needs of each, but perhaps not.

Thoughts?

[Bborie Park]

Heh. I have a ticket for rasters... #2526. I have yet to check out the API as I don't think the API has stabilized. Nor have I looked at the contrib package that demos it....

​http://www.postgresql.org/docs/0.0/static/test-shm-mq.html

[robe]

Oh cool :)

[Bborie Park]

My wish list for DBWs...

1. on-demand: workers are forked as needed

2. generic: workers aren't specific to a particular task but are given instructions which are then acted upon.

3. user-defined: a GUC to specify how many workers per operation. this does have a problem with overloading a machine.

[pramsey]

Ticket looks suspiciously like an email. No action item here.