Horton

Re: Re: Refresh Publication takes hours and doesn´t finish

Fabrízio de Royes Mello <fabrizio@timbira.com.br>

View thread View on postgr.es
From: Fabrízio de Royes Mello <fabrizio@timbira.com.br>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: PegoraroF10 <marcos@f10.com.br>, Peter Eisentraut <peter.eisentraut@2ndquadrant.com>, Postgres General <pgsql-general@postgresql.org>
Date: 2019-05-20T21:37:16Z
Lists: pgsql-hackers, pgsql-general 
Em seg, 20 de mai de 2019 às 18:30, Tom Lane <tgl@sss.pgh.pa.us> escreveu:
>
> Hmm ... given that pg_get_publication_tables() shouldn't return any
> duplicate OIDs, it does seem unnecessarily inefficient to put it in
> an IN-subselect condition.  Peter, is there a reason why this isn't
> a straight lateral join?  I get a much saner-looking plan from
>
>     FROM pg_publication P, pg_class C
> -        JOIN pg_namespace N ON (N.oid = C.relnamespace)
> -   WHERE C.oid IN (SELECT relid FROM
pg_get_publication_tables(P.pubname));
> +        JOIN pg_namespace N ON (N.oid = C.relnamespace),
> +        LATERAL pg_get_publication_tables(P.pubname)
> +   WHERE C.oid = pg_get_publication_tables.relid;
>

And why not just JOIN direct with pg_publication_rel ?

Regards,

--
   Fabrízio de Royes Mello         Timbira - http://www.timbira.com.br/
   PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento

Commits

  1. Fix O(N^2) performance issue in pg_publication_tables view.

  2. Clean up the behavior and API of catalog.c's is-catalog-relation tests.