Thread: PgAdmin 3 startup
I have downloaded the latest snapshot of pgadmin3 (pgadmin3-20031228-Win32.zip) and connected to a database. PgAmin takes 150 seconds to complete its startup. (I have reported this problem previously, but just wanted to let you know that it remains with this snapshot) --- Michael
Attachment
Michael Shapiro wrote: > I have downloaded the latest snapshot of pgadmin3 > (pgadmin3-20031228-Win32.zip) and connected to a database. PgAmin > takes 150 seconds to complete its startup. > >2003-12-29 15:16:26 QUERY : Scalar query (delphi:5432): > SELECT COUNT(*) FROM(SELECT tgargs from pg_trigger trLEFT JOIN pg_depend dep ON dep.objid=tr.oid AND deptype = 'i'LEFT JOINpg_constraint co ON refobjid = co.oid AND contype = 'f'WHERE co.oid IS NULLGROUP BY tgargs HAVING count(1) = 3) AS foo >2003-12-29 15:16:26 QUERY : DEBUG: StartTransactionCommand > >2003-12-29 15:18:52 QUERY : DEBUG: CommitTransactionCommand > >2003-12-29 15:18:52 QUERY : Query result: 0 > > Apparently this query is the offending one. It really should finish quite fast. I wonder if you a) have a lot of unmigrated constraint triggers and/or b) a lot of tables and never vacuumed the system tables. Please check this and give some feedback. Regards, Andreas
Michael, *please* use the mailing list!!! Michael Shapiro wrote: > The only clue that I might be able to offer you is that we have > dropped and recreated the schemas in the database many many times > without dropping and recreating the database. Might that cause this > query to run slowly? Yes, that's why I mentioned VACUUMing. Regards, Andreas
At 10:12 PM 12/30/2003 +0100, Andreas Pflug wrote: >Michael, > > >Michael Shapiro wrote: > >>The only clue that I might be able to offer you is that we have dropped >>and recreated the schemas in the database many many times without >>dropping and recreating the database. Might that cause this query to run >>slowly? > >Yes, that's why I mentioned VACUUMing. > >Regards, >Andreas > However, vacuuming did not speed this up. So the question remains.. why so slow on the one database while al the others are fast. --- Michael
Michael Shapiro wrote: > At 10:12 PM 12/30/2003 +0100, Andreas Pflug wrote: > >> Michael, >> >> >> Michael Shapiro wrote: >> >>> The only clue that I might be able to offer you is that we have >>> dropped and recreated the schemas in the database many many times >>> without dropping and recreating the database. Might that cause this >>> query to run slowly? >> >> >> Yes, that's why I mentioned VACUUMing. >> >> Regards, >> Andreas >> > > However, vacuuming did not speed this up. So the question remains.. > why so slow on the one database while al the others are fast. > Try EXPLAIN on that query. Regards, Andreas
How do I cut and paste the results (in the Data Output window) so I can send them to you. The normal highlight / cut/paste doesn't seem to work. At 03:09 PM 12/31/2003 +0100, Andreas Pflug wrote: >Michael Shapiro wrote: > >>At 10:12 PM 12/30/2003 +0100, Andreas Pflug wrote: >> >>>Michael, >>> >>> >>>Michael Shapiro wrote: >>> >>>>The only clue that I might be able to offer you is that we have dropped >>>>and recreated the schemas in the database many many times without >>>>dropping and recreating the database. Might that cause this query to >>>>run slowly? >>> >>> >>>Yes, that's why I mentioned VACUUMing. >>> >>>Regards, >>>Andreas >> >>However, vacuuming did not speed this up. So the question remains.. why >>so slow on the one database while al the others are fast. >Try EXPLAIN on that query. > >Regards, >Andreas > --- Michael
At 03:09 PM 12/31/2003 +0100, Andreas Pflug wrote: >Michael Shapiro wrote: > >>At 10:12 PM 12/30/2003 +0100, Andreas Pflug wrote: >> >>>Michael, >>> >>> >>>Michael Shapiro wrote: >>> >>>>The only clue that I might be able to offer you is that we have dropped >>>>and recreated the schemas in the database many many times without >>>>dropping and recreating the database. Might that cause this query to >>>>run slowly? >>> >>> >>>Yes, that's why I mentioned VACUUMing. >>> >>>Regards, >>>Andreas >> >>However, vacuuming did not speed this up. So the question remains.. why >>so slow on the one database while al the others are fast. >Try EXPLAIN on that query. > >Regards, >Andreas > --- Michael
Attachment
Hi Michael, I can't see too much from this query plan, it just seems you have 321 triggers an 4750 dependencies which isn't too extraordinary much. But 48 seconds execution time *is* much. Please repost this to pgsql-performance, including the query, backend version, and modified server settings. I'm not deep enough in planner items to analyze this sufficiently. Please let me CCd on this topic so I can see what I should change in pgAdmin3 (if any). Regards, Andreas