Heikki Linnakangas wrote: > I could reproduce this on my laptop, standby is about 20% slower. I ran > oprofile, and what stands out as the difference between the master and > standby is that on standby about 20% of the CPU time is spent in > hash_seq_search(). The callpath is GetSnapshotDat() -> > KnownAssignedXidsGetAndSetXmin() -> hash_seq_search(). That explains the > difference in performance.
The slowdown is proportional to the max_connections setting in the standby. 20% slowdown might still be acceptable, but if you increase max_connections to say 1000, things get really slow. I wouldn't recommend max_connections=1000, of course, but I think we need to do something about this. Changing the KnownAssignedXids data structure from hash table into something that's quicker to scan. Preferably something with O(N), where N is the number of entries in the data structure, not the maximum number of entries it can hold as it is with the hash table currently. A quick fix would be to check if there's any entries in the hash table before scanning it. That would eliminate the overhead when there's no in-progress transactions in the master. But as soon as there's even one, the overhead comes back. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
