| From: | "Pierre C" <lists(at)peufeu(dot)com> |
|---|---|
| To: | "Greg Smith" <greg(at)2ndquadrant(dot)com>, "Dave Crooke" <dcrooke(at)gmail(dot)com> |
| Cc: | "Paul McGarry" <paul(at)paulmcgarry(dot)com>, pgsql-performance(at)postgresql(dot)org |
| Subject: | Re: shared_buffers advice |
| Date: | 2010-03-16 11:24:40 |
| Message-ID: | op.u9nrbeeteorkce@localhost |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
> -My warnings about downsides related to checkpoint issues with larger
> buffer pools isn't an opinion at all; that's a fact based on limitations
> in how Postgres does its checkpoints. If we get something more like
> Oracle's incremental checkpoint logic, this particular concern might go
> away.
Does PG issue checkpoint writes in "sorted" order ?
I wonder about something, too : if your DB size is smaller than RAM, you
could in theory set shared_buffers to a size larger than your DB provided
you still have enough free RAM left for work_mem and OS writes management.
How does this interact with the logic which prevents seq-scans hogging
shared_buffers ?
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Nikolas Everett | 2010-03-16 13:26:15 | Re: shared_buffers advice |
| Previous Message | Greg Smith | 2010-03-16 07:28:02 | Re: shared_buffers advice |