Alvaro Herrera <alvhe...@commandprompt.com> writes: > Excerpts from Dimitri Fontaine's message of vie mar 23 11:05:37 -0300 2012: > >> =# \d pg_extension_feature >> Table "pg_catalog.pg_extension_feature" >> Column | Type | Modifiers >> ------------+------+----------- >> extoid | oid | not null >> extfeature | name | not null >> Indexes: >> "pg_extension_feature_name_index" UNIQUE, btree (extfeature) >> "pg_extension_feature_oid_index" UNIQUE, btree (oid) >> "pg_extension_feature_extoid_name_index" btree (extoid, extfeature) >> >> We could maybe get rid of the (extoid, extfeature) index which is only >> used to get sorted output in list_extension_features() function, but I >> don't know how to do an ORDER BY scan without index in C (yet). >> >> The ordering is then used to maintain pg_depend when the list of >> provided features changes at upgrade time. We fetch the ordered list of >> “old” feature names then for each newly provided feature name we >> bsearch() the old list, which then needs to be properly ordered. > > Hm, couldn't it be done simply with a qsort()? Presumably there aren't > many feature entries to sort ...
Mmmm… Then we would need an index on extoid to be able to list features of a given extension, and that would be the only usage of such an index. I guess that having it include the feature's name is not so expensive as to try avoiding it and qsort() in the code rather than scan the index in order? Regards, -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
