Re: ADD/DROP INHERITS

From: Greg Stark <gsstark(at)mit(dot)edu>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Greg Stark <gsstark(at)mit(dot)edu>, pgsql-patches(at)postgresql(dot)org
Subject: Re: ADD/DROP INHERITS
Date: 2006-06-15 17:57:39
Message-ID: 87fyi69u98.fsf@stark.xeocode.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2006-06-15 18:02:12 Re: [PATCHES] PL/pgSQL: SELECT INTO EXACT
Previous Message Bruce Momjian 2006-06-15 17:49:05 Re: Re-thing PG_MODULE_MAGIC

Browse pgsql-patches by date

  From Date Subject
Next Message Bruce Momjian 2006-06-15 18:02:12 Re: [PATCHES] PL/pgSQL: SELECT INTO EXACT
Previous Message Bruce Momjian 2006-06-15 17:09:27 Re: return can contains any row or record functions