Re: Refresh Publication takes hours and doesn´t finish

From: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PegoraroF10 <marcos(at)f10(dot)com(dot)br>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: Refresh Publication takes hours and doesn´t finish
Date: 2019-05-23 13:08:37
Message-ID: 9285a255-3cf9-4bad-6e87-8668f179afa2@2ndquadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

On 2019-05-20 23:30, Tom Lane wrote:
> 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;

No reason I think, just didn't quite manage to recognize the possibility
of using LATERAL at the time.

--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to

Browse pgsql-general by date

  From Date Subject
Next Message bret_stern@machinemanagement.com 2019-05-23 13:35:27 Re: Data entry / data editing tools (more end-user focus).
Previous Message Thiemo Kellner 2019-05-23 10:51:37 Re: Table inheritance over schema boundaries possible

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2019-05-23 13:10:44 Re: Remove useless associativity/precedence from parsers
Previous Message Amit Khandekar 2019-05-23 12:09:21 Re: Minimal logical decoding on standbys