Re: Do we need so many hint bits?
От | Atri Sharma |
---|---|
Тема | Re: Do we need so many hint bits? |
Дата | |
Msg-id | CAOeZVieq+1wLqgqk7n+L4vYAYin9cu=vq0PEYUtWtKi3dENAaQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Do we need so many hint bits? (Jeff Davis <pgsql@j-davis.com>) |
Ответы |
Re: Do we need so many hint bits?
|
Список | 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:No, that is only for the process *clearing* the bit, and this already
> 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.
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 по дате отправления: