From: | Kevin Grittner <kgrittn(at)ymail(dot)com> |
---|---|
To: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Gurjeet Singh <gurjeet(at)singh(dot)im> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, PGSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Andres Freund <andres(at)2ndquadrant(dot)com> |
Subject: | Re: Proposing pg_hibernate |
Date: | 2014-07-03 14:11:54 |
Message-ID: | 1404396714.33727.YahooMailNeo@web122303.mail.ne1.yahoo.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> Overall I agree that following Robert's idea will increase the
> time to make database server up and reach a state where apps can
> connect and start operations,
I agree that warming the cache before beginning to apply WAL would
be best.
> but I think atleast with such an approach we can claim that after
> warming buffers with pg_hibernator apps will always have
> performance greater than equal to the case when there is no
> pg_hibernator.
I would be careful of this claim in a NUMA environment. The whole
reason I investigated NUMA issues and wrote the NUMA patch is that
a customer had terrible performance which turned out to be caused
by cache warming using a single connection (and thus a single
process, and thus a single NUMA memory node). To ensure that this
doesn't trash performance on machines with many cores and memory
nodes, it would be best to try to spread the data around among
nodes. One simple way of doing this would be to find some way to
use multiple processes in hopes that they would run on difference
CPU packages.
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2014-07-03 14:16:01 | Re: Setting PG-version without recompiling |
Previous Message | Shigeru Hanada | 2014-07-03 14:00:18 | Re: [v9.5] Custom Plan API |