| From: | Atri Sharma <atri(dot)jiit(at)gmail(dot)com> |
|---|---|
| To: | Merlin Moncure <mmoncure(at)gmail(dot)com> |
| Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
| Subject: | Re: StrategyGetBuffer optimization, take 2 |
| Date: | 2013-08-05 16:52:22 |
| Message-ID: | CAOeZVifybhJLEi2p=d+8UDLakcr2f+fNeCOgvh=5BMOpMa0pfQ@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> optimization 2: refcount is examined during buffer allocation without
> a lock. if it's > 0, buffer is assumed pinned (even though it may not
> in fact be) and sweep continues
+1.
I think this shall not lead to much problems, since a lost update
cannot,IMO, lead to disastrous result. At most, a buffer page can
survive for an extra clock sweep.
> optimization 3: sweep does not wait on buf header lock. instead, it
> does 'try lock' and bails if the buffer is determined pinned. I
> believe this to be one of the two critical optimizations
+1 again. I believe the try lock will be a sort of filter before the
actual check, hence reducing the contention.
Regards,
Atri
--
Regards,
Atri
l'apprenant
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2013-08-05 16:53:24 | Re: Re: ALTER SYSTEM SET command to change postgresql.conf parameters (RE: Proposal for Allow postgresql.conf values to be changed via SQL [review]) |
| Previous Message | Andres Freund | 2013-08-05 16:46:11 | Re: Re: ALTER SYSTEM SET command to change postgresql.conf parameters (RE: Proposal for Allow postgresql.conf values to be changed via SQL [review]) |