Re: REINDEX backend filtering

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
Date: 2021-03-03 05:56:59
Message-ID: 20210303055659.wowfwt2nyxuynzqg@nol
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

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
indexes-to-be-processed size

Attachment Content-Type Size
v5-0001-Add-a-new-OUTDATED-filtering-facility-for-REINDEX.patch text/x-diff 17.3 KB
v5-0002-Add-a-outdated-option-to-reindexdb.patch text/x-diff 14.3 KB

In response to


Browse pgsql-hackers by date

  From Date Subject
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