Re: unlogged tables vs. GIST

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> I think that might be acceptable from a performance point of view -
> after all, if the index is unlogged, you're saving the cost of WAL -
> but I guess I still prefer a generic solution to this problem (a
> generalization of GetXLogRecPtrForTemp) rather than a special-purpose
> solution based on the nitty-gritty of how GiST uses these values.
> What's the difference between storing this value in pg_control and,
> say, the OID counter?

Well, the modularity argument is that GiST shouldn't have any special
privileges compared to a third-party index AM. (I realize that
third-party AMs already have problems plugging into WAL replay, but
that doesn't mean we should create more problems.)

We could possibly dodge that objection by regarding the global counter
as some sort of generic "unlogged operation counter", available to
anybody who needs it. It would be good to have a plausible example of
something else needing it, but assume somebody can think of one.

The bigger issue is that the reason we don't have to update pg_control
every other millisecond is that the OID counter is capable of tracking
its state between checkpoints without touching pg_control, that is it
can emit WAL records to track its increments. I think that we should
insist that GiST do likewise, even if we give it some space in
pg_control. Remember that pg_control is a single point of failure for
the database, and the more often it's written to, the more likely it is
that something will go wrong there.

So I guess what would make sense to me is that we invent an "unlogged
ops counter" that is managed exactly like the OID counter, including
having WAL records that are treated as consuming some number of values
in advance. If it's 64 bits wide then the WAL records could safely be
made to consume quite a lot of values, like a thousand or so, thus
reducing the actual WAL I/O burden to about nothing.

regards, tom lane