| From: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Greg Stark <gsstark(at)mit(dot)edu>, Pierre C <lists(at)peufeu(dot)com>, Greg Smith <greg(at)2ndquadrant(dot)com>, Dave Crooke <dcrooke(at)gmail(dot)com>, Paul McGarry <paul(at)paulmcgarry(dot)com>, pgsql-performance(at)postgresql(dot)org |
| Subject: | Re: shared_buffers advice |
| Date: | 2010-03-16 21:49:03 |
| Message-ID: | 20100316214903.GH3037@alvh.no-ip.org |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
Tom Lane escribió:
> Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
> > Maybe it would make more sense to try to reorder the fsync calls
> > instead.
>
> Reorder to what, though? You still have the problem that we don't know
> much about the physical layout on-disk.
Well, to block numbers as a first step.
However, this reminds me that sometimes we take the block-at-a-time
extension policy too seriously. We had a customer that had a
performance problem because they were inserting lots of data to TOAST
tables, causing very frequent extensions. I kept wondering whether an
allocation policy that allocated several new blocks at a time could be
useful (but I didn't try it). This would also alleviate fragmentation,
thus helping the physical layout be more similar to logical block
numbers.
--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2010-03-16 21:58:34 | Re: shared_buffers advice |
| Previous Message | Tom Lane | 2010-03-16 21:39:26 | Re: shared_buffers advice |