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...