On Wed, Mar 20, 2024 at 7:19 PM Alexander Korotkov <aekorotkov@gmail.com> wrote:
> On Mon, Mar 11, 2024 at 3:44 PM Maxim Orlov <orlovmg@gmail.com> wrote:
> > On Tue, 6 Feb 2024 at 09:22, Michael Paquier <michael@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
