Re: Support for REINDEX CONCURRENTLY

On Sun, Jan 27, 2013 at 1:37 AM, Andres Freund <andres@2ndquadrant.com>wrote:

> On 2013-01-25 14:11:39 +0900, Michael Paquier wrote:
>
> It sure isn't optimal, but it should do the trick if you use the
> hash_seq stuff to iterate the hash afterwards. And you could use it to
> map to the respective locks et al.
>
> If you prefer other ways to implement it I guess the other easy solution
> is to add the values without preventing duplicates and then sort &
> remove duplicates in the end. Probably ends up being slightly more code,
> but I am not sure.
>
Indeed, I began playing with the HTAB functions and it looks that the only
correct way to use that would be to use a hash table using as key the index
OID with as entry:
- the index OID itself
- the concurrent OID
And a second hash table with parent relation OID as key and as output the
LOCKTAG for each parent relation.


> I don't think we can leave the quadratic part in there as-is.
>
Sure, that is understandable.
-- 
Michael Paquier
http://michael.otacoo.com