| From: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
|---|---|
| To: | Andres Freund <andres(at)2ndquadrant(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-01-25 05:11:39 |
| Message-ID: | CAB7nPqTqxT2OXWtwwSogpqh-AMA9yzMDtjDv3rp=tM7k7ZMfQQ@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, Jan 24, 2013 at 3:41 AM, Andres Freund <andres(at)2ndquadrant(dot)com>wrote:
> I think the usage of list_append_unique_oids in
> ReindexRelationsConcurrently might get too expensive in larger
> schemas. Its O(n^2) in the current usage and schemas with lots of
> relations/indexes aren't unlikely candidates for this feature.
> The easist solution probably is to use a hashtable.
>
I just had a look at the hashtable APIs and I do not think it is adapted to
establish the list of unique index OIDs that need to be built concurrently.
It would be of a better use in case of mapping the indexOids with something
else, like the concurrent Oids, but still even with that the code would be
more readable if let as is.
--
Michael Paquier
http://michael.otacoo.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David Fetter | 2013-01-25 05:12:41 | Re: LATERAL, UNNEST and spec compliance |
| Previous Message | Michael Paquier | 2013-01-25 04:48:50 | Re: Support for REINDEX CONCURRENTLY |