Atsushi Ogawa <a_ogawa@hi-ho.ne.jp> writes:
> Tom Lane wrote:
>> Why is this better than the fix already in place?
> Because per-tuple context is reset many times. If per-tuple context is
> never used, the following codes of AllocSetReset become effective.
> /* Nothing to do if context has never contained any data */
> if (block == NULL)
> return;
Hm. It's still pretty ugly though, since fixing only those two places
isn't very exciting.
I went back and looked at your AllocSetReset patch from last May, and
liked it better on second consideration. The point I had missed before
is that even though we're adding an instruction to palloc, it's only
needed in the "slow" paths. The cases that we have to be worried about,
IMHO, are:
1. Loop containing palloc(s) and pfree(s).
2. Loop containing palloc(s) and MemoryContextReset.
3. Loop containing only MemoryContextReset.
(We need not worry about cases doing only palloc since that is obviously
not sustainable over any long period.) Case 1 is the one that was
bothering me, but in practice, once the loop is rolling the pallocs
should mostly be reusing previously-pfreed chunks. That is the "fast"
path through AllocSetAlloc, and it doesn't need any extra overhead
because it doesn't need to clear the alloc-set-is-empty flag --- the
set is clearly already nonempty if it has free chunks. There's enough
instructions in the other paths that one more isn't going to hurt.
In case 2 we're adding instructions to both palloc and
MemoryContextReset, for no gain :-( ... but again, these are in code
paths that aren't the fastest possible. I don't think it'll hurt
noticeably.
I notice also that MemoryContextIsEmpty could return a better answer
if we maintained a flag like this. This is not real important in the
current scheme of things, but might be more interesting someday.
I'll fix up the old patch and apply it. I think that's a better answer
than kluging up the aggregate functions themselves.
regards, tom lane