On 28/08/2018 20:47, Tom Lane wrote:
> Here's a proposed patch for this. It removes the hacking of the TOC list
> order, solving Peter's original problem, and instead sorts-by-size
> in the actual parallel dump or restore control code.
I have reviewed this patch. I haven't done any major performance tests
or the like, but the improvements are clear in principle.
It does solve the issue that I had originally reported, when I apply it
on top of my development branch.
Some small comments on the code:
Maybe add a ready_list_free() to go with ready_list_init(), instead of
calling pg_free(ready_list.tes) directly.
get_next_work_item() has been changed to remove the work item from the
ready_list. Maybe rename to something like pop_next_work_item()?
I'm confused by what ready_list_remove() is doing when it's not removing
the first item. It looks like it's removing all leading items up to the
i'th one. Is that what we want? In some cases, we are skipping over
things that we are not interested at all, so this would work, but if
we're just skipping over an item because of a lock conflict, then it's
not right.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
