Re: [HACKERS] Optimizing Read-Only Scalability

2009-05-17 Thread Simon Riggs
On Sat, 2009-05-16 at 23:36 -0400, Jignesh K. Shah wrote: > Simon Riggs wrote: > > > >>> 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 w

Re: [HACKERS] Optimizing Read-Only Scalability

2009-05-16 Thread Jignesh K. Shah
Simon Riggs wrote: On Thu, 2009-05-14 at 16:21 -0700, Josh Berkus wrote: 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

Re: [HACKERS] Optimizing Read-Only Scalability

2009-05-15 Thread Simon Riggs
On Thu, 2009-05-14 at 16:21 -0700, Josh Berkus wrote: > > 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. > > How muc

Re: [HACKERS] Optimizing Read-Only Scalability

2009-05-14 Thread Josh Berkus
Simon, 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. How much work would it be to work up a test patch? -- Josh Berkus P

Re: [HACKERS] Optimizing Read-Only Scalability

2009-05-14 Thread Simon Riggs
On Thu, 2009-05-14 at 14:06 -0400, Robert Haas wrote: > Supposing that the patch can be shown to improve performance for > all-read-only workloads, and supposing further that the patch can be > shown to have no material negative impact on write-heavy workloads, it > would also be interesting to t

Re: [HACKERS] Optimizing Read-Only Scalability

2009-05-14 Thread Robert Haas
On Thu, May 14, 2009 at 1:55 PM, Tom Lane wrote: > Robert Haas writes: >> On Thu, May 14, 2009 at 1:28 PM, Tom Lane wrote: >>> GetSnapshotData doesn't take an exclusive lock.  Neither does start or >>> end of a read-only transaction.  AFAIK there is no reason, and certainly >>> no shred of exper

Re: [HACKERS] Optimizing Read-Only Scalability

2009-05-14 Thread Simon Riggs
On Thu, 2009-05-14 at 13:28 -0400, Tom Lane wrote: > Simon Riggs writes: > > 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

Re: [HACKERS] Optimizing Read-Only Scalability

2009-05-14 Thread Tom Lane
Robert Haas writes: > On Thu, May 14, 2009 at 1:28 PM, Tom Lane wrote: >> GetSnapshotData doesn't take an exclusive lock.  Neither does start or >> end of a read-only transaction.  AFAIK there is no reason, and certainly >> no shred of experimental evidence, to think that ProcArrayLock >> content

Re: [HACKERS] Optimizing Read-Only Scalability

2009-05-14 Thread Robert Haas
On Thu, May 14, 2009 at 1:28 PM, Tom Lane wrote: > Simon Riggs writes: >> 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 d

Re: [HACKERS] Optimizing Read-Only Scalability

2009-05-14 Thread Tom Lane
Simon Riggs writes: > 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. GetSnapshotData doesn't t

[HACKERS] Optimizing Read-Only Scalability

2009-05-14 Thread Simon Riggs
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 transaction