From: | Gregory Stark <stark(at)enterprisedb(dot)com> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | <josh(at)agliodbs(dot)com>, <pgsql-hackers(at)postgresql(dot)org>, "Heikki Linnakangas" <heikki(at)enterprisedb(dot)com>, "Simon Riggs" <simon(at)2ndquadrant(dot)com>, "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, "Jeff Trout" <threshar(at)threshar(dot)is-a-geek(dot)com>, "Koichi Suzuki" <suzuki(dot)koichi(at)oss(dot)ntt(dot)co(dot)jp> |
Subject: | Re: [GENERAL] Slow PITR restore |
Date: | 2007-12-14 01:09:21 |
Message-ID: | 87prxam69q.fsf@oxford.xeocode.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-hackers |
"Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> The argument that Heikki actually made was that multiple parallel
> queries could use more of the I/O bandwidth of a multi-disk array
> than recovery could. Which I believe, but I question how much of a
> real-world problem it is. For it to be an issue, you'd need a workload
> that is almost all updates (else recovery wins by not having to
> replicate reads of pages that don't get modified) and the updates have
> to range over a working set significantly larger than physical RAM
> (else I/O bandwidth won't be the bottleneck anyway). I think we're
> talking about an extremely small population of real users.
Of course that describes most benchmarks pretty well...
I think of this as a scalability problem, not so much a sheer speed problem.
If Postgres isn't fast enough for you you should be able to buy a faster
processor or faster disk or faster something to run it faster. The problem
with this situation is that buying a faster raid controller doesn't help you.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's RemoteDBA services!
From | Date | Subject | |
---|---|---|---|
Next Message | Alex Vinogradovs | 2007-12-14 01:47:05 | Re: plpgsql trigger coredumps instance |
Previous Message | Tom Lane | 2007-12-14 01:08:50 | Re: plpgsql trigger coredumps instance |
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2007-12-14 01:19:01 | Negative LIMIT and OFFSET? |
Previous Message | Tom Lane | 2007-12-14 00:37:39 | Re: [GENERAL] Slow PITR restore |