Logical Replication - revisit `is_table_publication` function implementation - Mailing list pgsql-hackers

From Peter Smith
Subject Logical Replication - revisit `is_table_publication` function implementation
Date
Msg-id CAHut+Pti83yGaV5-DZU=AvJHxFDuoKW8_pjSedRham8SgZxLYA@mail.gmail.com
Whole thread
Responses Re: Logical Replication - revisit `is_table_publication` function implementation
List pgsql-hackers
Hi, after confirming my understanding of pg_publication_rel [1], I
revisited some logical replication internal functions.

Specifically.
* The `is_table_publication` function is for checking if the
publication has a clause like "FOR TABLE t1".
* The `is_schema_publication` function is for checking if the
publication has a clause like "FOR TABLES IN SCHEMA s1".

Notice that neither of these ("FOR TABLE", "FOR TABLES IN SCHEMA")
clauses are possible simultaneously with "FOR ALL TABLES".

And we can readily discover if "FOR ALL TABLES" (aka `puballtables`)
is present from the pubform.

We can use this to optimise and simplify the implementations of the
`is_schema_publication` and `is_table_publication` functions.

PSA patch v1.

AFAICT, the result is:
- less code + simpler logic. e.g. is_table_publication does not check
'prexcept' anymore
- more efficient. e.g. skips unnecessary scanning when puballtables is true.
- more consistent. e.g., both functions are now almost identical.

Thoughts?

======
[1] https://www.postgresql.org/message-id/flat/CAHut%2BPv1UKR_bxmN7wcCCpQveHoYprvH-hbdFq8gsaH1Ye7B_w%40mail.gmail.com

Kind Regards,
Peter Smith.
Fujitsu Australia

Attachment

pgsql-hackers by date:

Previous
From: John Naylor
Date:
Subject: Re: [PATCH] Simplify SortSupport implementation for macaddr
Next
From: Lukas Fittl
Date:
Subject: Re: Reduce timing overhead of EXPLAIN ANALYZE using rdtsc?