Craig Ringer wrote: > It'll need to separate "running queries" from "running processes", or > start threading backends, so that one way or the other a single query > can benefit from the capabilities of multiple CPUs. The same separation, > or a move to async I/O, might be needed to get one query to concurrently > read multiple partitions of a table, or otherwise get maximum benefit > from high-capacity I/O subsystems when running just a few big, expensive > queries. > > Otherwise I'm wondering if PostgreSQL will begin really suffering in > performance on workloads where queries are big and expensive but there > are relatively few of them running at a time.
Agreed. We certainly are going to have to go in that direction someday. We have TODO items for these. -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + None of us is going to be here forever. + -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
