Re: Slow PITR restore
От | Joshua D. Drake |
---|---|
Тема | Re: Slow PITR restore |
Дата | |
Msg-id | 20071212102543.3333809d@commandprompt.com обсуждение исходный текст |
Ответ на | Re: Slow PITR restore (Jeff Trout <threshar@torgo.978.org>) |
Ответы |
Re: Slow PITR restore
|
Список | pgsql-general |
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, 12 Dec 2007 13:13:35 -0500 Jeff Trout <threshar@threshar.is-a-geek.com> wrote: > > On Dec 12, 2007, at 1:02 PM, Gregory Stark wrote: > > > > I'm not sure what you guys' expectations are, but if you're > > restoring 5 > > minutes worth of database traffic in 8 seconds I wouldn't be > > complaining. > > > > Depending on your transaction mix and what percentage of it is > > read- only > > select queries you might reasonably expect the restore to take as > > long as it > > took to generate them... > > > > in this case it was 24hrs of data - about 1500 wal segments. During > this time the machine was nearly complete idle and there wasn't very > much IO going on (few megs/sec). Exactly. Which is the point I am making. Five minutes of transactions is nothing (speaking generally).. In short, if we are in recovery, and we are not saturated the I/O and at least a single CPU, there is a huge amount of optimization *somewhere* to be done. Tom is also correct, we should test this on 8.3. Joshua D. Drake - -- The PostgreSQL Company: Since 1997, http://www.commandprompt.com/ Sales/Support: +1.503.667.4564 24x7/Emergency: +1.800.492.2240 Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate SELECT 'Training', 'Consulting' FROM vendor WHERE name = 'CMD' -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHYCerATb/zqfZUUQRArdeAJ9D89Qi7xCqFDUOpUgKQ/QigwHNPwCdFQfN Dl8svUbMi40WExyd93MCIzw= =MEhU -----END PGP SIGNATURE-----
В списке pgsql-general по дате отправления: