Re: Foreign key wierdness - Mailing list pgsql-hackers

From Hannu Krosing
Subject Re: Foreign key wierdness
Date
Msg-id 1043343893.1368.9.camel@localhost.localdomain
Whole thread Raw
In response to Re: Foreign key wierdness  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom Lane kirjutas K, 22.01.2003 kell 22:30:
> Didier Moens <Didier.Moens@dmb001.rug.ac.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@tm.ee>


pgsql-hackers by date:

Previous
From: Hannu Krosing
Date:
Subject: Re: Terrible performance on wide selects
Next
From: Hannu Krosing
Date:
Subject: Re: Call for objections: put back OIDs in CREATE TABLE