Horton
Menu

Re: Support for REINDEX CONCURRENTLY

Andres Freund <andres@2ndquadrant.com>

View thread
From: Andres Freund <andres@2ndquadrant.com>
To: Peter Eisentraut <peter_e@gmx.net>
Cc: Michael Paquier <michael.paquier@gmail.com>, Fujii Masao <masao.fujii@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>, Simon Riggs <simon@2ndquadrant.com>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2013-03-03T12:54:36Z
Lists: pgsql-hackers 
On 2013-03-01 16:32:19 -0500, Peter Eisentraut wrote:
> REINDEX CONCURRENTLY resets the statistics in pg_stat_user_indexes,
> whereas plain REINDEX does not.  I think they should be preserved in
> either case.

Yes. Imo this further suggests that it would be better to switch the
relfilenodes (+indisclustered) of the two indexes instead of switching
the names. That would allow to get rid of the code for moving over
dependencies as well.
Given we use an exclusive lock for the switchover phase anyway, there's
not much point in going for the name-based switch. Especially as some
eventual mvcc-correct system access would be fine with the relfilenode
method.

Greetings,

Andres Freund

-- 
 Andres Freund	                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Background worker processes

  2. Fix assorted bugs in CREATE/DROP INDEX CONCURRENTLY.

  3. Work around unportable behavior of malloc(0) and realloc(NULL, 0).

  4. Properly set relpersistence for fake relcache entries.