| 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: | Whole Thread | Raw Message | 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 |