Re: Slow PITR restore

From: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
To: Gregory Stark <stark(at)enterprisedb(dot)com>
Cc: Simon Riggs <simon(at)2ndquadrant(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, Jeff Trout <threshar(at)threshar(dot)is-a-geek(dot)com>, pgsql-general(at)postgresql(dot)org, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Slow PITR restore
Date: 2007-12-13 13:18:04
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-general pgsql-hackers

Gregory Stark wrote:
> "Simon Riggs" <simon(at)2ndquadrant(dot)com> writes:
> > It's a good idea, but it will require more complex code. I prefer the
> > simpler solution of using more processes to solve the I/O problem.
> Huh, I forgot about that idea. Ironically that was what I suggested when
> Heikki described the problem.
> I think it's more complex than using posix_fadvise. But it's also more
> ambitious. It would allow us to use not only the full random access i/o
> bandwidth but also allow us to use more cpu. In cases where the database fits
> entirely in ram and we're recovering many many operations modifying the same
> blocks over and over that might help a lot.

Actually, if you are modifying the same blocks over and over it will
help *less*, because applying each record needs to occur only after the
previous records that modify the same block have been applied.

So you have two possibilities: you skip that record and try to apply the
next one, hoping that that record applies to a block that's not locked,
(which means you have to remember the skipped record and apply it
sometime in the future), or you put the process to sleep until the lock
has been released.

Alvaro Herrera
"La conclusión que podemos sacar de esos estudios es que
no podemos sacar ninguna conclusión de ellos" (Tanenbaum)

In response to


Browse pgsql-general by date

  From Date Subject
Next Message Alvaro Herrera 2007-12-13 13:31:19 Re: [GENERAL] Slow PITR restore
Previous Message John D. Burger 2007-12-13 13:12:56 Re: Better alternative for Primary Key then serial??

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2007-12-13 13:22:21 Re: result of convert_to is bytea
Previous Message Gregory Stark 2007-12-13 13:13:33 New style of hash join proposal