On Mon, Jun 8, 2020 at 5:11 AM Magnus Hagander <magnus@hagander.net> wrote:
> I agree that we should consider changing it *if* it does not come with a substantial overhead, but that has to be
shown.
I think the big overhead is that you log the old version of each row's
primary key (or whatever the replica identity is) when performing an
UPDATE or DELETE. So if you test it with integer keys probably it's
not bad, and I suspect (though I haven't looked) that we don't do the
extra logging when they key hasn't changed. But if you have wide text
columns as keys and you update them a lot then things might not look
so good. I think in the bad cases for this feature the overhead is
vastly more than going from minimal to replica.
As many people here probably know, I am in general skeptical of this
kind of change. It's based on the premise that reconfiguring the
system is either too hard for users to figure out, or too disruptive
because they'll need a restart. I tend to feel that the first problem
should be solved by making it easier to figure out, and the second one
should be solved by not requiring a restart. I don't think that's easy
engineering, because while I think barriers help, they only address
one relatively small aspect of what's probably a pretty difficult
engineering problem. But the real-life analogue of what's being
proposed here seems to be "the people who are buying this house might
not be able to figure out how to turn the lights on if they need more
light, so let's just turn on all the lights before we hand over the
keys, and that way if they just leave them on forever it'll be cool."
To which any reasonable person would say - "if your electrical
switches are that hard to locate and use, that house has got a serious
design problem."
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
