Re: Read-ahead and parallelism in redo recovery
От | Florian G. Pflug |
---|---|
Тема | Re: Read-ahead and parallelism in redo recovery |
Дата | |
Msg-id | 47C81B69.9060103@phlo.org обсуждение исходный текст |
Ответ на | Read-ahead and parallelism in redo recovery ("Pavan Deolasee" <pavan.deolasee@gmail.com>) |
Ответы |
Re: Read-ahead and parallelism in redo recovery
Re: Read-ahead and parallelism in redo recovery Re: Read-ahead and parallelism in redo recovery |
Список | pgsql-hackers |
Pavan Deolasee wrote: > What I am thinking is if we can read ahead these blocks in the shared > buffers and then apply redo changes to them, it can potentially > improve things a lot. If there are multiple read requests, kernel (or > controller ?) can probably schedule the reads more efficiently. The same holds true for index scans, though. Maybe we can find a solution that benefits both cases - something along the line of a bgreader process > Btw, isn't our redo recovery completely physical in nature ? I mean, > can we replay redo logs related to a block independent of other > blocks ? The reason I am asking because if thats the case, ISTM we > can introduce parallelism in recovery by splitting and reordering the > xlog records and then run multiple processes to do the redo > recovery. > I'd say its "physical" on the tuple level (We just log the new tuple on an update, not how to calculate it from the old one), but "logical" on the page level (We log the fact that a tuple was inserted on a page, but e.g. the physical location of the tuple on the page can come out differently upon replay). It's even "more logical" for indices, because we log page splits as multiple wal records, letting the recovery process deal with synthesizing upper-level updates should we crash in the middle of a page split. Additionally, we log full-page images as a safeguard against torn page writes. Those would need to be considered as a kind of "reorder barrier" in any parallel restore scenario, I guess. I know that Simon has some ideas about parallel restored, though I don't know how he wants to solve the dependency issues involved. Perhaps by not parallelizing withon one table or index...
В списке pgsql-hackers по дате отправления: