Re: Foreign key wierdness
От | Dave Page |
---|---|
Тема | Re: Foreign key wierdness |
Дата | |
Msg-id | 03AF4E498C591348A42FC93DEA9661B88587@mail.vale-housing.co.uk обсуждение исходный текст |
Ответ на | Foreign key wierdness ("Dave Page" <dpage@vale-housing.co.uk>) |
Ответы |
Re: Foreign key wierdness
|
Список | pgsql-hackers |
> -----Original Message----- > From: Didier Moens [mailto:Didier.Moens@dmb001.rug.ac.be] > Sent: 22 January 2003 16:05 > To: Dave Page > Cc: Tom Lane; PostgreSQL Hackers Mailing List > Subject: Re: [HACKERS] Foreign key wierdness > > > 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, > ... I'd never have guessed that one, despite noting that particular change in the code some time ago. Oh well... Anyway, that was changed in pgAdmin because I got a couple of complaints about it's use of int4 for migrated serial/autonumber columns. One user was migrating some *very* large numbers from a SQL Server. From what Tom has said in his reponse, I think the answer for you Didier is to remap your integer columns to int8 instead of int4 and see what happens. When I get a couple of minutes I will look at putting a Serials as... Option in the type map. Regards, Dave.
В списке pgsql-hackers по дате отправления: