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

Re: [PERFORM] Re: [PERFORM] Re: [PERFORM] Re: [PERFORM] Re: 回复: [PERFORM] PG as in-memory db? How to warm up and re-populate buffers? How to read in all tuples into memory?

From: Tomas Vondra <tv(at)fuzzy(dot)cz>
To: Claudio Freire <klaussfreire(at)gmail(dot)com>
Cc: "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org>
Subject: Re: [PERFORM] Re: [PERFORM] Re: [PERFORM] Re: [PERFORM] Re: 回复: [PERFORM] PG as in-memory db? How to warm up and re-populate buffers? How to read in all tuples into memory?
Date: 2012-03-03 00:30:18
Message-ID: 4F51661A.4090903@fuzzy.cz (view raw or flat)
Thread:
Lists: pgsql-performance
On 2.3.2012 03:05, Claudio Freire wrote:
> On Thu, Mar 1, 2012 at 10:13 PM, Tomas Vondra <tv(at)fuzzy(dot)cz> wrote:
>>
>> Maybe. I still am not sure how fsync=off affects the eviction in your
>> opinion. I think it does not (or just very remotely) and you were saying
>> the opposite. IMHO the eviction of (dirty) buffers is either very fast
>> or slow, no matter what the fsync setting is.
> 
> I was thinking page cleanup, but if you're confident it doesn't happen
> on a read-only database, I'd have to agree on all your other points.
> 
> I have seen a small amount of writes on a read-only devel DB I work
> with, though. Usually in the order of 100kb/s writes per 10mb/s reads
> - I attributed that to page cleanup. In that case, it can add some
> wait time to fsync, even though it's really a slow volume of writes.
> If you're right, I'm thinking, it may be some other thing... atime
> updates maybe, I'd have to check the filesystem configuration I guess.

I'd guess those writes were caused by hint bits (~ page cleanup, but
that's a one-time thing and should be fixed by VACUUM FREEZE right after
the load). Or maybe it was related to runtime stats (i.e. pgstat).

T.

In response to

pgsql-performance by date

Next:From: Claus StadlerDate: 2012-03-03 22:43:17
Subject: ...WHERE TRUE" condition in union results in bad query pla
Previous:From: Tom LaneDate: 2012-03-02 19:31:00
Subject: Re: Inefficient min/max against partition (ver 9.1.1)

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