Optimizing Read-Only Scalability
От | Simon Riggs |
---|---|
Тема | Optimizing Read-Only Scalability |
Дата | |
Msg-id | 1242320503.3843.562.camel@ebony.2ndQuadrant обсуждение исходный текст |
Ответы |
Re: Optimizing Read-Only Scalability
Re: Optimizing Read-Only Scalability |
Список | pgsql-hackers |
In a thread on -perform it has been observed that our Read-Only scalability is not as good as it could be. One problem being that we need to scan the whole of the ProcArray to derive a snapshot, which becomes the dominant task with many users. If we think about a situation where write transactions happen infrequently, then the likelihood is that we end up with xmin==xmax most of the time. If our last snapshot had xmin=xmax and the xmax hasn't changed since our last snapshot then we don't need to scan the procarray at all, just look at the header. So we can optimize away the scan through the procarray by doing two "if" tests, one outside of the lock, one inside. In normal running, both will be optimized away, though in read-only periods we would avoid much work. We don't need to change the API to GetSnapshotData since the snapshot is statically allocated and unless newly created will contain the "last" snapshot's data. Interesting? -- Simon Riggs www.2ndQuadrant.comPostgreSQL Training, Services and Support
В списке pgsql-hackers по дате отправления: