Re: Add Index-level REINDEX with multiple jobs
От | Alexander Korotkov |
---|---|
Тема | Re: Add Index-level REINDEX with multiple jobs |
Дата | |
Msg-id | CAPpHfduPAqjm_E80n2mVSVLi_5vKbTthjOr2p-ktX5UbipzJFw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Add Index-level REINDEX with multiple jobs (Alexander Korotkov <aekorotkov@gmail.com>) |
Ответы |
Re: Add Index-level REINDEX with multiple jobs
|
Список | pgsql-hackers |
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
Вложения
В списке pgsql-hackers по дате отправления: