| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Didier Moens <Didier(dot)Moens(at)dmb001(dot)rug(dot)ac(dot)be> |
| Cc: | 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-22 20:30:10 |
| Message-ID: | 23829.1043267410@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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?
> 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Curtis Faith | 2003-01-22 20:38:33 | Re: Windows Build System |
| Previous Message | D. Hageman | 2003-01-22 20:17:03 | Namespace/Table Visibility Behavior Issues |