Re: changeset generation v5-01 - Patches & git tree

On 2013-06-28 10:49:26 -0400, Tom Lane wrote:
> Andres Freund <andres@2ndquadrant.com> writes:
> > On 2013-06-28 08:41:46 -0400, Robert Haas wrote:
> >> The alternative I previously proposed was to make the WAL records
> >> carry the relation OID.  There are a few problems with that: one is
> >> that it's a waste of space when logical replication is turned off, and
> >> it might not be easy to only do it when logical replication is on.
> >> Also, even when logic replication is turned on, things that make WAL
> >> bigger aren't wonderful.  On the other hand, it does avoid the
> >> overhead of another index on pg_class.
> 
> > I personally favor making catalog modifications a bit more more
> > expensive instead of increasing the WAL volume during routine
> > operations.
> 
> This argument is nonsense, since it conveniently ignores the added WAL
> entries created as a result of additional pg_class index manipulations.

Huh? Sure, pg_class manipulations get more expensive. But in most
clusters pg_class modifications are by far the minority compared to the
rest of the updates performed.

> Robert's idea sounds fairly reasonable to me; another 4 bytes per
> insert/update/delete WAL entry isn't that big a deal, and it would
> probably ease many debugging tasks as well as what you want to do.
> So I'd vote for including the rel OID all the time, not conditionally.

Ok, I can sure live with that. I don't think it's a problem to make it
conditionally if we want to. Making it unconditional would sure make WAL
debugging in general more pleasant though.

> The real performance argument against the patch as you have it is that
> it saddles every PG installation with extra overhead for pg_class
> updates whether or not that installation ever has or ever will make use
> of changeset generation --- unlike including rel OIDs in WAL entries,
> which might be merely difficult to handle conditionally, it's flat-out
> impossible to turn such an index on or off.  Moreover, even if one is
> using changeset generation, the overhead is being imposed at the wrong
> place, ie the master not the slave doing changeset extraction.

There's no required slaves for doing changeset extraction
anymore. Various people opposed that pretty violently, so it's now all
happening on the master. Which IMHO turned out to be the right decision.

We can do it on Hot Standby nodes, but its absolutely not required.

> But that's not the only problem, nor even the worst one IMO.  I said
> before that a syscache with a non-unique key is broken by design, and
> I stand by that estimate.  Even assuming that this usage doesn't create
> bugs in the code as it stands, it might well foreclose future changes or
> optimizations that we'd like to make in the catcache code.

Since the only duplicate key that possibly can occur in that cache is
InvalidOid, I wondered whether we could define a 'filter' that prohibits
those ending up in the cache? Then the cache would be unique.

Greetings,

Andres Freund

-- Andres Freund                       http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services