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: Claudio Freire <klaussfreire(at)gmail(dot)com>
To: Tomas Vondra <tv(at)fuzzy(dot)cz>
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-02 02:05:15
Message-ID: CAGTBQpYKeMhGMtoX31sL=_Np-VZpDPVYDEoOYYw9ckfvYmYaeA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

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.

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Anssi Kääriäinen 2012-03-02 12:51:53 Re: Large insert and delete batches
Previous Message Andrew Dunstan 2012-03-02 01:17:14 Re: PG as in-memory db? How to warm up and re-populate buffers? How to read in all tuples into memory?