Re: Add parallelism and glibc dependent only options to reindexdb
От | Tomas Vondra |
---|---|
Тема | Re: Add parallelism and glibc dependent only options to reindexdb |
Дата | |
Msg-id | 20190702101240.dipk7wphmsoitlw3@development обсуждение исходный текст |
Ответ на | Re: Add parallelism and glibc dependent only options to reindexdb (Julien Rouhaud <rjuju123@gmail.com>) |
Список | pgsql-hackers |
On Tue, Jul 02, 2019 at 10:45:44AM +0200, Julien Rouhaud wrote: >On Tue, Jul 2, 2019 at 10:28 AM Tomas Vondra ><tomas.vondra@2ndquadrant.com> wrote: >> >> I wonder why this is necessary: >> >> pg_log_error("cannot reindex glibc dependent objects and a subset of objects"); >> >> What's the reasoning behind that? It seems like a valid use case to me - >> imagine you have a bug database, but only a couple of tables are used by >> the application regularly (the rest may be archive tables, for example). >> Why not to allow rebuilding glibc-dependent indexes on the used tables, so >> that the database can be opened for users sooner. > >It just seemed wrong to me to allow a partial processing for something >that's aimed to prevent corruption. I'd think that if users are >knowledgeable enough to only reindex a subset of indexes/tables in >such cases, they can also discard indexes that don't get affected by a >collation lib upgrade. I'm not strongly opposed to supporting if >though, as there indeed can be valid use cases. > I don't know, it just seems like an unnecessary limitation. >> BTW now that we allow rebuilding only some of the indexes, it'd be great >> to have a dry-run mode, were we just print which indexes will be rebuilt >> without actually rebuilding them. > >+1. If we end up doing the filter in the backend, we'd have to add >such option in the REINDEX command, and actually issue all the orders >to retrieve the list. Hmmm, yeah. FWIW I'm not requesting v0 to have that feature, but it'd be good to design the feature in a way that allows adding it later. regards -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-hackers по дате отправления: