Re: [PATCHES] WIP: avoiding tuple construction/deconstruction overhead

2005-03-18 Thread Bruce Momjian
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

Re: [PATCHES] WIP: avoiding tuple construction/deconstruction overhead

2005-03-18 Thread a_ogawa
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

Re: [PATCHES] WIP: avoiding tuple construction/deconstruction overhead

2005-03-17 Thread Tom Lane
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

Re: [PATCHES] WIP: avoiding tuple construction/deconstruction overhead

2005-03-17 Thread a_ogawa
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

[PATCHES] WIP: avoiding tuple construction/deconstruction overhead

2005-03-15 Thread Tom Lane
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