From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Robins <robins(at)pobox(dot)com>, Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Eliminating PD_ALL_VISIBLE, take 2 |
Date: | 2013-07-02 02:52:57 |
Message-ID: | 1372733577.19747.91.camel@jdavis |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, 2013-07-01 at 16:05 -0400, Robert Haas wrote:
> Well, I don't believe there's any way to really eliminate the
> contention concern completely. There's no way around the fact that it
> means more access to the visibility map, and I've seen recent (albeit
> circumstantial thus far) evidence that that can be a real problem.
> The buffer mapping locks are a problem, too, so anything that means
> more page accesses can't be taken lightly. I agree your proposed
> changes reduce the chances of problems; I don't agree that they
> eliminate them.
If you have a 1000-page table that is being accessed concurrently, that
requires 1000 pins. My patch would make that 1001, which doesn't sound
very scary to me.
1. Do you agree that concurrent access to 1000-page tables is not a
problem with the design of my patch?
2. Can you be more specific about the scenarios that you *are* concerned
about? Preferably in a form that could be tested on a 64-core box; but
at least some kind of analysis involving numbers. "More page accesses"
is scary, but completely meaningless without saying how *many* more and
in which situations.
Regards,
Jeff Davis
From | Date | Subject | |
---|---|---|---|
Next Message | Tatsuo Ishii | 2013-07-02 03:16:18 | Large object + FREEZE? |
Previous Message | Jeff Davis | 2013-07-02 02:39:46 | Re: Eliminating PD_ALL_VISIBLE, take 2 |