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...
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
