From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: mosbench revisited |
Date: | 2011-08-08 13:22:50 |
Message-ID: | CA+TgmoYF-+9fCJXr1nS3a4QSpj5JKt6Q_JjrmQRNECEj4HVYaQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sat, Aug 6, 2011 at 1:43 PM, Jeff Janes <jeff(dot)janes(at)gmail(dot)com> wrote:
> The approach is to move the important things from a LWLock to a
> spinlock, and to not do any locking for increments to clock-hand
> increment and numBufferAllocs.
> That means that some buffers might occasionally get inspected twice
> and some might not get inspected at all during any given clock cycle,
> but this should not lead to any correctness problems. (Disclosure:
> Tom didn't like this approach when it was last discussed.)
>
> I just offer this for whatever it is worth to you--I'm not proposing
> it as an actual patch to be applied.
Interesting approach.
> When data fits in RAM but not shared_buffers, maybe the easiest fix is
> to increase shared_buffers. Which brings up the other question I had
> for you about your work with Nate's celebrated loaner machine. Have
> you tried to reproduce the performance problems that have been
> reported (but without public disclosure of how to reproduce) with
> shared_buffers > 8GB on machines with RAM >>8GB ?
No. That's on my list, but thus far has not made it to the top of
said list. :-(
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2011-08-08 13:29:39 | Re: mosbench revisited |
Previous Message | Robert Haas | 2011-08-08 13:20:09 | Re: vacuumlo patch |