|From:||Julien Rouhaud <rjuju123(at)gmail(dot)com>|
|To:||Magnus Hagander <magnus(at)hagander(dot)net>|
|Cc:||Michael Paquier <michael(at)paquier(dot)xyz>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>|
|Subject:||Re: REINDEX backend filtering|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
On Tue, Mar 02, 2021 at 12:01:55PM +0800, Julien Rouhaud wrote:
> So, long running reindex due to some gigantic and/or numerous indexes on a
> single (or few) table is not something that we can solve, but inefficient
> reindex due to wrong table size / to-be-reindexed-indexes-size correlation can
> be addressed.
> I would still prefer to go to backend implementation, so that all client tools
> can benefit from it by default. We could simply export the current
> index_has_oudated_collation(oid) function in sql, and tweak pg_dump to order
> tables by the cumulated size of such indexes as you mentioned below, would
> that work for you?
> Also, given Thomas proposal in a nearby email this function would be renamed to
> index_has_oudated_dependencies(oid) or something like that.
Please find attached v5 which address all previous comments:
- consistently use "outdated"
- use REINDEX (OUTDATED) grammar (with a new unreserved OUTDATED keyword)
- new --outdated option to reindexdb
- expose a new "pg_index_has_outdated_dependency(regclass)" SQL function
- use that function in reindexdb --outdated to sort tables by total
|Next Message||Michael Paquier||2021-03-03 06:03:28||Re: Buildfarm failure in crake|
|Previous Message||Andres Freund||2021-03-03 05:56:06||Re: buildfarm windows checks / tap tests on windows|