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
