rehashing catalog cache id 14 for pg_opclass; 17 tups, 8 buckets

Hi all

When running following query in psql (server and client version 10 with 
replication on Debian 9), I get the message mentioned in the subject. I 
have not found much searching the internet. There were suggestions on 
bloat so I ran "vacuum (verbose, full, analyze)" but the message remains.

with PRO_UNNESTED_TYPES as(
   select
     oid as PROOID,
     PRONAME,
     unnest(PROARGTYPES) as PROARGTYPE,
     PRONAMESPACE,
     PROOWNER
   from
     PG_CATALOG.PG_PROC
) select
   P.PRONAME,
   string_agg(
     T.TYPNAME,
     ', '
   ) as PARAMETER_LIST_STRING,
   G.GRANTEE
from
   PRO_UNNESTED_TYPES P
inner join PG_CATALOG.PG_TYPE T on
   P.PROARGTYPE = T.OID
inner join PG_CATALOG.PG_NAMESPACE N on
   P.PRONAMESPACE = N.OID
inner join INFORMATION_SCHEMA.ROUTINE_PRIVILEGES G on
   -- copied from INFORMATION_SCHEMA.ROUTINE_PRIVILEGES source
  -- as seen in DBeaver 4.3.2
(
     (
       P.PRONAME::text || '_'::text
     )|| P.PROOID::text
   )::INFORMATION_SCHEMA.SQL_IDENTIFIER = G.SPECIFIC_NAME
where
   N.NSPNAME = current_user
   and G.GRANTEE != current_user
group by
   P.PROOID,
   P.PRONAME,
   G.GRANTEE
order by
   P.PRONAME asc,
   G.GRANTEE asc,
   PARAMETER_LIST_STRING asc;

I use this installation to develop and for the time being I install and 
re-install a couple of functions only 3 tables an a single view. I 
install in a proper schema which gets re-created at the beginning of my 
install script.

I ran also following statement I found on the net to get an idea on 
bloat in my database.

pg_depend_reference_index    944 kB
pg_proc    904 kB
pg_depend_depender_index    880 kB
pg_largeobject_metadata_oid_index    8192 bytes
pg_enum_typid_sortorder_index    8192 bytes
pg_enum_typid_label_index    8192 bytes
pg_largeobject_loid_pn_index    8192 bytes
pg_enum_oid_index    8192 bytes
pg_statistic_ext_oid_index    8192 bytes
pg_statistic_ext_name_index    8192 bytes

I am quite ok with pg_proc, however I do not know why the depend tables 
are so big and whether this is normal. The rest is fine by me too.

select
   relname,
   pg_size_pretty(
     pg_relation_size(C.oid)
   )
from
   pg_class C
left join pg_namespace N on
   (
     N.oid = C.relnamespace
   )
where
   nspname = 'pg_catalog'
order by
   2 desc limit 10;

I do not feel that my DB has a problem but I was taken aback a bit when 
I first saw the message in the subject.

I would be grateful about a bit shed light.

Kind regards Thiemo

-- 
Öffentlicher PGP-Schlüssel:
http://pgp.mit.edu/pks/lookup?op=get&search=0xCA167FB0E717AFFC