Alvaro Herrera <alvherre@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
