On Wed, Mar 20, 2024 at 7:19 PM Alexander Korotkov <aekorot...@gmail.com> wrote: > On Mon, Mar 11, 2024 at 3:44 PM Maxim Orlov <orlo...@gmail.com> wrote: > > On Tue, 6 Feb 2024 at 09:22, Michael Paquier <mich...@paquier.xyz> wrote: > >> The problem may be actually trickier than that, no? Could there be > >> other factors to take into account for their classification, like > >> their sizes (typically, we'd want to process the biggest one first, I > >> guess)? > > > > > > Sorry for a late reply. Thanks for an explanation. This is sounds > > reasonable to me. > > Svetlana had addressed this in the patch v2. > > I think this patch is a nice improvement. But it doesn't seem to be > implemented in the right way. There is no guarantee that > get_parallel_object_list() will return tables in the same order as > indexes. Especially when there is "ORDER BY idx.relpages". Also, > sort_indices_by_tables() has quadratic complexity (probably OK since > input list shouldn't be too lengthy) and a bit awkward. > > I've revised the patchset. Now appropriate ordering is made in SQL > query. The original list of indexes is modified to match the list of > tables. The tables are ordered by the size of its greatest index, > within table indexes are ordered by size. > > I'm going to further revise this patch, mostly comments and the commit > message.
Here goes the revised patch. I'm going to push this if there are no objections. ------ Regards, Alexander Korotkov
v4-0001-Add-the-index-level-REINDEX-with-multiple-jobs.patch
Description: Binary data
