On 2013-07-01 14:16:55 -0400, Tom Lane wrote: > Alvaro Herrera <alvhe...@2ndquadrant.com> writes: > > So the question is, do we take the overhead of the new index (which > > means overhead on DML operations -- supposedly rare) or do we take the > > overhead of larger WAL records (which means overhead on all DDL > > operations)? > > > Note we can make either thing apply to only people running logical > > replication. > > I don't believe you can have or not have an index on pg_class as easily > as all that. The choice would have to be frozen at initdb time, so > people would have to pay the overhead if they thought there was even a > small possibility that they'd want logical replication later.
It should be possible to create the index in a single database when we start logical replication in that database? Running the index creation with a fixed oid shouldn't require too much code. The oid won't be reused by other pg_class entries since it would be a system one. Alternatively we could always create the index's pg_class/index entry but mark it as !indislive when logical replication isn't active for that database. Then activating it would just require rebuilding that index. But then, I am not fully convinced that's worth the trouble since I don't think pg_class index maintenance is the painspot in DDL atm. > Flipping the content of WAL records might not be a terribly simple thing > to do either, but at least in principle it could be done during a > postmaster restart, without initdb. The main patch combines various booleans in the heap wal records into a flags variable, so there should be enough space to keep track of it without increasing size. Makes size calculations a bit more annoying though as we use the xlog record length to calculate the heap tuple's length, but that's not a large problem. So we could just set the XLOG_HEAP_CONTAINS_CLASSOID flag if wal_level >= WAL_LEVEL_LOGICAL. Wal decoding then can throw a tantrum if it finds a record without it and we're done. We could even make that per database, but that seems to be something for the future. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
