Hi Tom,
> Well, it's hard to be sure what the problem is when you're not showing > us a problem case ... but I notice that this indexscan is estimated > awfully high: Whenever I do it manually it works fast. But in the log I see lots of slow ones. Could it be caused by auto vacuum? Or by check pointing or WAL writing? Are there way to check that? > > -> Index Scan using > > pg_depend_reference_index on pg_depend dep (cost=0.00..64942.17 > > rows=247 width=12) (actual time=396.542..1547.172 rows=22 loops=1) > > Index Cond: (refobjid = 30375069::oid) > > The reason is not far to seek: the scan is checking only the second > index key, meaning that it has to scan the entire index. (I am > surprised it didn't use a seqscan instead. Are you using enable_seqscan > = off? Not a great idea.) Since you know you are looking for a table, > you could improve matters by adding a constraint on refclassid: > > dep.refclassid = 'pg_class'::regclass enable_setscan is on. Is there a way to analyze/vacuum those tables? I will look if I can also improve the query to be more exact. Bye, Guy. -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
