On Mon, Oct 7, 2013 at 9:32 AM, Andres Freund <andres@2ndquadrant.com> wrote:
>> - RelationIsDoingTimetravel is still a crappy name. How about
>> RelationRequiredForLogicalDecoding? And maybe the reloption
>> treat_as_catalog_table can become required_for_logical_decoding.
>
> Hm. I don't really like the name, required seems to imply that it's
> necessary to turn this on to get data replicated in that relation. How
> about "accessible_during_logical_decoding" or "user_catalog_table"? The
> latter would allow us to use it to add checks for user relations used in
> indexes which need a treatment similar to enums.
user_catalog_table is a pretty good description, but should we worry
about the fact that logical replication isn't mentioned in there
anywhere?
In what way do you feel that it's more clear to say *accessible
during* rather than *required for* logical decoding?
I was trying to make the naming consistent; i.e. if we have
RelationRequiredForLogicalDecoding then name the option to match.
>> All in all, it seems to me that we shouldn't try to punt. Maybe we
>> should have something that works like ALTER TABLE name CLUSTER ON
>> index_name to configure which index should be used for logical
>> replication. Possibly this same syntax could be used as ALTER
>> MATERIALIZED VIEW to set the candidate key for that case.
>
> How about using the current logic by default but allow to tune it
> additionally with an option like that?
I'm OK with defaulting to the primary key if there is one, but I think
that no other candidate key should be entertained unless the user
configures it. I think the behavior we get without that will be just
too weird. We could use the same logic you're proposing here for
CLUSTER, too, but we don't; that's because we've (IMHO, rightly)
decided that the choice of index is too important to be left to
chance.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
