Re: Do we need so many hint bits? - Mailing list pgsql-hackers

From Atri Sharma
Subject Re: Do we need so many hint bits?
Date
Msg-id CAOeZVieq+1wLqgqk7n+L4vYAYin9cu=vq0PEYUtWtKi3dENAaQ@mail.gmail.com
Whole thread Raw
In response to Re: Do we need so many hint bits?  (Jeff Davis <pgsql@j-davis.com>)
Responses Re: Do we need so many hint bits?  (Jeff Davis <pgsql@j-davis.com>)
List pgsql-hackers



On Sun, Nov 18, 2012 at 10:43 PM, Jeff Davis <pgsql@j-davis.com> wrote:
On Sun, 2012-11-18 at 15:19 +0100, Andres Freund wrote:
> On Sunday, November 18, 2012 03:07:01 AM Jeff Davis wrote:
> > Process A (process that clears a VM bit for a data page):
> >   1. Acquires exclusive lock on data buffer
> >   2. Acquires exclusive lock on VM buffer
> >   3. clears VM bit
> >   4. Releases VM buffer lock
> >   5. Releases data buffer lock
>
> Well, but right this is a rather big difference. If vm pages get
> unconditionally locked all the time we will have a huge source of new
> contention as they are shared between so many heap pages.

No, that is only for the process *clearing* the bit, and this already
happens. I am not planning on introducing any new locks, aside from the
buffer header lock when acquiring a pin. And I plan to keep those pins
for long enough that those don't matter, either.

Regards,
        Jeff Davis



--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Sorry If I am being a bit naive, but shouldnt a simple mutex work in the case when a process wants to change the VM bit in cache?

Mutex would be cheaper than locks.

Atri

--
Regards,
 
Atri
l'apprenant

pgsql-hackers by date:

Previous
From: Josh Berkus
Date:
Subject: Re: Materialized views WIP patch
Next
From: Atri Sharma
Date:
Subject: Re: Do we need so many hint bits?