Tom Lane <tgl@sss.pgh.pa.us> writes:
> If you're happy with the code looking directly at pg_constraint then
> I see no reason to change it. I just mentioned the relcache because
> I thought you were concerned about the performance of a pg_constraint
> search.
I'm not concerned with the performance hit of doing a linear scan on
pg_constraint or pg_attribute.
I am slightly concerned about repeatedly calling SearchSysCacheExistsAttName
But using relcache would mean a O(n^2) search across the attributes which
might be even worse. I'm unclear how efficient the SysCache lookup function
is. If it's a hash table lookup it might be slower but more scalable than an
O(n^2) match against the relcache anyways.
And I'm slightly concerned with the O(n^2) constraint matching. If someone has
100+ constraints it may be somewhat disappointing to have the operation have a
noticeable delay. 1,000 constraints means a million calls to strcmp.
Realistically though 1,000 check constraints would be pretty unlikely. 100
constraints might be on the edge of reasonableness and 10,000 calls to strcmp
is probably also at the edge of reasonableness too.
--
greg
