On Sat, Sep 24, 2005 at 08:20:47PM -0400, Rod Taylor wrote: > On Sat, 2005-09-24 at 18:59 -0500, Jim C. Nasby wrote: > > I have a client with a database that contains 4000 relations according > > to vacuum verbose, and \d in psql is painfully slow. In particular... > > > > -> Seq Scan on pg_class c (cost=0.00..2343.09 rows=6124 width=73) > > (actual time=0.325..22100.840 rows=16856 loops=1) > > Filter: (((relkind = 'r'::"char") OR (relkind = 'v'::"char") OR > > (relkind = 'S'::"char") OR (relkind = ''::"char")) AND > > pg_table_is_visible(oid)) > > > > That's off my laptop, but they're seeing similar issues on an 8-way > > Opteron as well... > > > > I've messed around with adding indexes to a copy of pg_class to no > > avail. Any ideas on how to improve the performance? > > It is probably the visibility checks. Is a \d fast if you include the > full name (schema.table)? > > I brought this up a while ago and Tom has since rearranged some of the > psql queries to move the visibility check to come after the other where > clause segments. > > > It would be nice if the cost of the function could be added somehow -- > even if it was just a low, medium or high setting. This would allow the > planner to shuffle the where clause executing ordering around in a > reasonable manner.
\d tablename is fast, yes. Maybe instead of re-arranging the query it would make more sense to roll the visibility check into the query itself (probably using a new system view). -- Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED] Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461 ---------------------------(end of broadcast)--------------------------- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
