Dimitri wrote:
What I discovered so far with all your help: - the impact of a planner - the impact of the analyze target - the impact of prepare / execute - scalability limit on 32 cores
You've received good advice on how to minimize the impact of the first three points, and using those techniques should bring a benefit. But I'm pretty surprised by the bad scalability you're seeing and no-one seems to have a good idea on where that limit is coming from. At a quick glance, I don't see any inherent bottlenecks in the schema and workload.
If you could analyze where the bottleneck is with multiple cores, that would be great. With something like oprofile, it should be possible to figure out where the time is spent.
My first guess would be the WALInsertLock: writing to WAL is protected by that and it an become a bottleneck with lots of small UPDATE/DELETE/INSERT transactions. But a profile would be required to verify that.
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
