Re: Support for REINDEX CONCURRENTLY

From: Andres Freund <andres(at)2ndquadrant(dot)com>
To: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Simon Riggs <simon(at)2ndquadrant(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Support for REINDEX CONCURRENTLY
Date: 2013-02-12 13:04:18
Message-ID: 20130212130418.GC12852@alap2.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2013-02-12 21:54:52 +0900, Michael Paquier wrote:
> > Changing only toast_save_datum:
> >
> > [... code ...]
> >
> Yes, I have spent a little bit of time looking at the code related to
> retoastindxid and thought about this possibility. It would make the changes
> far easier with the existing patch, it will also be necessary to update the
> catalog pg_statio_all_tables to make the case where OID is InvalidOid
> correct with this catalog.

What I proposed above wouldn't need the case where toastrelidx =
InvalidOid, so no need to worry about that.

> However, I do not think it is as clean as simply
> removing retoastindxid and have all the toast APIs running consistent
> operations, aka using only RelationGetIndexList.

Sure. This just seems easier as it really only requires changes inside
toast_save_datum() and which mostly avoids any overhead (not even
additional palloc()s) if there is only one index.
That would lower the burden of proof that no performance regressions
exist (which I guess would be during querying) and the amount of
possibly external breakage due to removing the field...

Not sure whats the best way to do this when committing. But I think you
could incorporate something like the proposed to continue working on the
patch. It really should only take some minutes to incorporate it.

Greetings,

Andres Freund

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2013-02-12 13:19:41 Re: Support for REINDEX CONCURRENTLY
Previous Message Kevin Grittner 2013-02-12 12:57:21 Re: parser_analyze freeing memory which is later referenced