Re: Avoiding repeated snapshot computation - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Avoiding repeated snapshot computation
Date
Msg-id 29164.1322333787@sss.pgh.pa.us
Whole thread Raw
In response to Re: Avoiding repeated snapshot computation  (Pavan Deolasee <pavan.deolasee@gmail.com>)
Responses Re: Avoiding repeated snapshot computation
List pgsql-hackers
Pavan Deolasee <pavan.deolasee@gmail.com> writes:
> On Sat, Nov 26, 2011 at 10:43 PM, Robert Haas <robertmhaas@gmail.com> 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?

In the end, getting a snapshot is exactly about copying information out
of shared memory.  Perhaps it would be more productive to think about
how we could further modify the ProcArray representation to reduce the
impedance mismatch between it and the snapshot representation, rather
than introducing a second shared-memory copy of the same information.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Pavan Deolasee
Date:
Subject: Re: Avoiding repeated snapshot computation
Next
From: Peter Geoghegan
Date:
Subject: Re: Inlining comparators as a performance optimisation