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
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 |
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 |