Re: Support for REINDEX CONCURRENTLY
| От | Michael Paquier |
|---|---|
| Тема | Re: Support for REINDEX CONCURRENTLY |
| Дата | |
| Msg-id | CAB7nPqQNCUtAUaLb=xSCjAaH5oRhkKu9e62DriuPMdBks365NA@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Support for REINDEX CONCURRENTLY (Andres Freund <andres@2ndquadrant.com>) |
| Список | pgsql-hackers |
On Sun, Jan 27, 2013 at 1:37 AM, Andres Freund <andres@2ndquadrant.com> wrote:
Michael PaquierIt sure isn't optimal, but it should do the trick if you use theOn 2013-01-25 14:11:39 +0900, Michael Paquier wrote:
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.
- 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.
--
--
http://michael.otacoo.com
В списке pgsql-hackers по дате отправления: