Skip site navigation (1) Skip section navigation (2)

Re: BBU Cache vs. spindles

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: James Mansion <james(at)mansionfamily(dot)plus(dot)com>, Greg Smith <greg(at)2ndquadrant(dot)com>, Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, Bruce Momjian <bruce(at)momjian(dot)us>, jd(at)commandprompt(dot)com, Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com>, Steve Crawford <scrawford(at)pinpointresearch(dot)com>, pgsql-performance(at)postgresql(dot)org, Ben Chobot <bench(at)silentmedia(dot)com>
Subject: Re: BBU Cache vs. spindles
Date: 2010-10-29 15:57:06
Message-ID: 2777.1288367826@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-performancepgsql-www
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Thu, Oct 28, 2010 at 5:26 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> It's true that we don't know whether write() causes an immediate or
>> delayed disk write, but we generally don't care that much. What we do
>> care about is being able to ensure that a WAL write happens before the
>> data write, and with mmap we don't have control over that.

> Well, we COULD keep the data in shared buffers, and then copy it into
> an mmap()'d region rather than calling write(), but I'm not sure
> there's any advantage to it.  Managing address space mappings is a
> pain in the butt.

In principle that ought to be right about the same speed as using
write() to copy the data from shared buffers to kernel disk buffers,
anyway.

			regards, tom lane

In response to

pgsql-performance by date

Next:From: BenDate: 2010-10-29 16:16:13
Subject: Re: partitioning question 1
Previous:From: Aidan Van DykDate: 2010-10-29 15:56:09
Subject: Re: BBU Cache vs. spindles

pgsql-www by date

Next:From: Robert HaasDate: 2010-10-29 16:44:06
Subject: Re: BBU Cache vs. spindles
Previous:From: Aidan Van DykDate: 2010-10-29 15:56:09
Subject: Re: BBU Cache vs. spindles

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group