Pavan Deolasee wrote: > On Sun, Nov 27, 2011 at 12:26 AM, Tom Lane <[email protected]> wrote: > > Pavan Deolasee <[email protected]> writes: > >> On Sat, Nov 26, 2011 at 10:43 PM, Robert Haas <[email protected]> > >> wrote: > >>> Furthermore, it's > >>> hard to understand how this could be a net improvement in the general > >>> case, because now both B and F are copying everything twice (once to > >>> the shared area and one to backend-local memory) instead of just once > >>> (to backend-local memory) and C and D are sleeping (yikes!). > > > >> Yes, B and F pay a price of double copy. But I think it can be a net > >> saving because C and D (and many more hopefully) don't need to > >> recompute the snapshot again by going over a potentially large > >> ProcArray. > > > > Like Robert, I'm finding it hard to believe that this isn't going to be > > a net pessimization in as many or more cases as it'd be a win. ?Also, > > didn't we just get rid of most of the issue of "going over a large > > ProcArray" with the move of hot members to a separate array? > > > > Yeah, separating the PGPROC members has helped a lot. But that does > not reduce the number of GetSnapshotData calls. It only makes each > call less expensive. As I said, I had seen 15-20% improvement with not > even a slightly tuned patch, so I am optimistic about the potential of > the approach.
Agreed. I think there is great potential here. We have been stumped at how to reduce the overhead of this for years, and it seems you are now on a promising path. -- Bruce Momjian <[email protected]> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
