> If you aren't using it now, and thus don't know how fast or slow it would be on your data and queries, why would you care about percentage speed ups?

I'm working under the assumption that similar operations between PostgreSQL and MySQL for operations that aren't using an advanced feature that the other plainly doesn't support will be roughly comparable in performance. I understand this isn't true, but it's useful in that it gives me a baseline to work with when reasoning without forcing me to migrate my application (or at least a significant portion of the data) to PostgreSQL just to test. If I'm then confronted with a feature that one supports and the other doesn't that has the capability to in some cases reduce the query time by an order of magnitude, then it's starts approaching the criteria needed for me to invest that time to see if it's worth migrating.

> I gather that people considering migrating who want some reassurance before investing time in testing should be more interested in such things things as benchmarks that show whether PostgreSQL can saturate your hardware for various query types

Isn't that exactly what this is? Throwing CPU cores at aggregating data to reduce time? I asked for benchmarks regarding this specific feature, to see what type of gain we were talking about with this. I didn't ask for comparisons to other databases because those benchmarks are generally harder to perform fairly, so I would have been (and am) happy with comparative gain benchmarks.