Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-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

pgsql-hackers by date

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

pgsql-patches by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group