Re: Foreign key wierdness

From: Hannu Krosing <hannu(at)tm(dot)ee>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Didier Moens <Didier(dot)Moens(at)dmb001(dot)rug(dot)ac(dot)be>, Dave Page <dpage(at)vale-housing(dot)co(dot)uk>, PostgreSQL Hackers Mailing List <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Foreign key wierdness
Date: 2003-01-23 17:44:53
Message-ID: 1043343893.1368.9.camel@localhost.localdomain
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane kirjutas K, 22.01.2003 kell 22:30:
> Didier Moens <Didier(dot)Moens(at)dmb001(dot)rug(dot)ac(dot)be> writes:
> > I did some extensive testing using PostgreSQL 7.3.1 (logs and results
> > available upon request), and the massive slowdown is NOT related to
> > qualified tablename syntax or (lack of) VACUUM ANALYZE, but to the
> > following change :
>
> > pgAdminII 1.4.2 :
> > -------------------
> > CREATE TABLE articles (
> > article_id integer DEFAULT
> > nextval('"articles_article_id_key"'::text) NOT NULL,
> > ...
>
> > pgAdminII 1.4.12 :
> > --------------------
> > CREATE TABLE articles (
> > article_id bigint DEFAULT nextval('"articles_article_id_key"'::text)
> > NOT NULL,
> > ...
>
> Ah-hah, and I'll bet that the column being linked to this one by the
> foreign key constraint is still an integer?

This should at least give out a NOTICE or ABORT or generate a functional
index, not a plain one.

> > With two tables each containing some 20.000 entries, the fk creation
> > time between both of them increases from ~ 1.8 secs to ~ 221 secs.
>
> Seems odd that the cost would get *that* much worse. Maybe we need to
> look at whether the FK checking queries need to include explicit casts
> ...
>
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
>
> http://archives.postgresql.org
--
Hannu Krosing <hannu(at)tm(dot)ee>

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Hannu Krosing 2003-01-23 17:51:54 Re: Call for objections: put back OIDs in CREATE TABLE
Previous Message Hannu Krosing 2003-01-23 17:42:26 Re: Terrible performance on wide selects