I am very excited there has been so much reduction in tuple processing
overhead in the past few weeks. This is always and area I thought
needed improvement, and its great to see it.
We will certainly have some big performance improvements in 8.1 because
we already have several (e.g. SMP) and we
Tom Lane wrote:
> a_ogawa <[EMAIL PROTECTED]> writes:
> > (1)We can improve compare_heap() by using TableTupleSlot instead of
> > HeapTuple. Please see attached patch.
>
> Did you measure any performance improvement from that? I considered it
> but thought it would likely be
a_ogawa <[EMAIL PROTECTED]> writes:
> (1)We can improve compare_heap() by using TableTupleSlot instead of
> HeapTuple. Please see attached patch.
Did you measure any performance improvement from that? I considered it
but thought it would likely be a wash or a loss, because in most cases
only one
Tom Lane wrote:
> Attached is the current state of a patch to reduce the overhead of
> passing tuple data up through many levels of plan nodes.
It is a good idea.
I think that this patch improves performance of the whole executor.
I have three comments.
(1)We can
Attached is the current state of a patch to reduce the overhead of passing
tuple data up through many levels of plan nodes. It's not tested enough
to apply yet, but I thought I'd put it out for comment. It seems to get
about a factor of 4 speedup on Miroslav's nested-joins example (above
and beyo