Re: Foreign key wierdness - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Foreign key wierdness
Date
Msg-id 23829.1043267410@sss.pgh.pa.us
Whole thread Raw
In response to Re: Foreign key wierdness  ("Dave Page" <dpage@vale-housing.co.uk>)
Responses Re: Foreign key wierdness  (Hannu Krosing <hannu@tm.ee>)
Re: Foreign key wierdness  (Didier Moens <moensd@xs4all.be>)
List pgsql-hackers
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?

> 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


pgsql-hackers by date:

Previous
From: "D. Hageman"
Date:
Subject: Namespace/Table Visibility Behavior Issues
Next
From: Viacheslav N Tararin
Date:
Subject: WIn32 port