Some explanations:
"parallel plans" in postgres9.6+ will do what you want: speed up a single query by kicking off parallel execution processes.
Aurora "parallel query" for MySQL is something completely different, although it also results in what you want.
Aurora (for MySQL and postgres) has a special distributed storage layer that keeps 6 redundant copies, which can be used for read-replicas and for failure recovery. "parallel query" leverages this storage layer (which comprises storage with associated CPUs to manage the storage) to perform some query computation, off-loading the DB VM.
For example, filtering out rows and cols not relevant to the query can be pushed down to the storage layer, instead of reading all the data back to the VM and discarding them there.
So in summary:
"parallel plans" in postgres9.6+ creates parallel execution processes inside the VM
"parallel query" in Aurora pushes down computation into the storage layer, offloading the VM.
Answers to your Qs:
- Correct
- Maybe: see above. Depends on the benefit you get by pushing down data filtering to the storage layer.
- According to AWS blog, "parallel query" for postgres is under development:
"We are launching with support for MySQL 5.6, and are working on support for MySQL 5.7 and PostgreSQL."
https://aws.amazon.com/blogs/aws/new-parallel-query-for-amazon-aurora/
I think some "significant" boost to postgres for analytics is necessary to support "real-time operational analytics" on a transactional postgres system. "parallel plans" in 9.6+ is a start. Aurora "parallel query" is another, different approach. There might be other approaches to speeding up analytics on postgres ... I'd like to see such solutions on multiple Clouds beyond AWS: Azure, GCP.
I have submitted a request for Azure - please upvote there if you agree:
https://feedback.azure.com/forums/597976-azure-database-for-postgresql/suggestions/35794984-transactional-db-with-analytics