Re: small smgr refactoring

On Mon, Jan 19, 2004 at 06:20:21PM -0500, Tom Lane wrote:
> Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl> writes:
> > (Well, it changes an ad-hoc linked
> > list into a proper List).
>
> Why? AFAICT that just makes the code bigger, uglier, and slower ...

Oh, does it? Hmm.

When I originally wrote this, it used FastList. The idea was that every
subtransaction has its own FastList, and that at subtransaction commit,
the list is appended to the parent's list. If the subtrasaction ends,
the list is walked and each file created inside the subtransaction is
deleted, and files marked for deletion are forgotten. (i.e. do nothing,
and the structs are released when the memory context disappears.)

It used FastList because append was a fast operation. It now uses List
because Neil is going to make List fast at append ... now that you ask,
it could probably just use lcons ...

(OTOH if List makes the code bigger and uglier, why is it used all
around the backend? I might buy the slower part, though.)

> I am pretty dubious of PendingDeletesBeginXact, too,

That one I might have a hard time justifying. I think I left that
because I had trouble at bootstrap. I will try building without this
routine to see if it works (it's really a pain to have a slow computer
-- I try to rebuild the least). But probably I'll have to add it later,
when the list converges in part of a more complex structure. But then,
maybe it won't be needed even in that situation.

> and of moving this list out of TopMemoryContext. Please justify.

Huh? TopMemoryContext is certainly a bad place for the allocation. The
elements certainly do not have to live beyond transaction end; I don't
see the point in use TopMemoryContext for this.

--
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
"La experiencia nos dice que el hombre peló millones de veces las patatas,
pero era forzoso admitir la posibilidad de que en un caso entre millones,
las patatas pelarían al hombre" (Ijon Tichy)