Though there is a description for the profile in doc/FAQ_DEV:
You can also compile with profiling to see what functions are taking
execution time. The backend profile files will be deposited in the
pgsql/data/base/dbname directory.
The backend profile files is deposited in the pgsql/data
?
Well, I measured the performance today. As a result, I confirmed the
second part of my patch is unnecessary as you pointed it out.
Thanks for comment and applying patch.
a_ogawa wrote:
In SQL that uses 'like' operator, wchareq is used to compare characters.
At the head of wchareq, length
Tom Lane [EMAIL PROTECTED] writes:
a_ogawa [EMAIL PROTECTED] writes:
It is a reasonable idea. However, the majority part of MemSet was not
able to be avoided by this idea. Because the per-tuple contexts are used
at the early stage of executor.
Drat. Well, what about
Tom Lane [EMAIL PROTECTED] writes:
And I'm worried about adding even a small amount of overhead to
palloc/pfree --- on the vast majority of the profiles I look at, those
are more expensive than AllocSetReset.
I don't worry about palloc. Because overhead increases only
Tom Lane [EMAIL PROTECTED] writes:
a_ogawa [EMAIL PROTECTED] writes:
In SQL that executes aggregation, AllocSetReset is called many times and
spend a lot of cycles.
This patch saves the cycles spent by AllocSetReset.
Hmm. It doesn't seem like this could be a big win
In SQL that executes aggregation, AllocSetReset is called many times and
spend a lot of cycles.
This patch saves the cycles spent by AllocSetReset.
An idea of the patch is to add a flag to AllocSetContext. This flag
shows whether AllocSetReset should work.
The effect of
In SQL that uses 'like' operator, wchareq is used to compare character.
At the head of wchareq, length of character is compared by
using pg_mblen. Therefore, pg_mblen is executed many times, and it
becomes a bottleneck.
This patch makes a short cut, and reduces execution
I forgot to attach a patch. I do post once again.
In SQL that uses 'like' operator, wchareq is used to compare characters.
At the head of wchareq, length of (multibyte) character is compared by
using pg_mblen. Therefore, pg_mblen is executed many times, and it
becomes a
Attached patch improves ExecMakeFunctionResultNoSets, etc.
This patch uses InitFunctionCallInfoData macro instead of MemSet to
initialize FunctionCallInfoData.
An idea of this patch discussed in the "FunctionCallN improvement" thread.
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 wash
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
I remaked patch for "Cache last known per-tuple offsets to speed
long tuple access" that is in TODO list.
The point of this patch is as follows:
(1)Add fields to TupleTableSlot and TupleTableData.
This fields are for holding the tuple disassembly information.
(2)Add the
Thank you for advice.
I am going to remake a patch, in order to make it simple.
The plan of a new patch is as follows.
(1)Add fields to TupleTableSlot and TupleTableData.
This fields are for holding the tuple disassembly information.
(2)Add the codes which
I made a patch for "Cache last known per-tuple offsets to speed
long tuple access" that is in TODO list.
This problem was discussed on hackers-list as "Terrible performance
on wide selects".
The point of this problem is nocachegetattr() used from ExecEvalVar().
If tuple
14 matches
Mail list logo
