Patch applied. Thanks. (The first if == NULL test was already in CVS).
---
a_ogawa wrote:
Tom Lane [EMAIL PROTECTED] writes:
a_ogawa [EMAIL PROTECTED] writes:
It is a reasonable idea. However, the majority part
Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
Patch applied. Thanks. (The first if == NULL test was already in CVS).
The first if == NULL test was the only part I wanted to apply ...
I do not think this patch is a performance win in general.
Attached is the part I backed
Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
Patch applied. Thanks. (The first if == NULL test was already in CVS).
The first if == NULL test was the only part I wanted to apply ...
I do not think this patch is a performance win in general.
OK, patch reverted. a_ogawa,
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.
---
On Thu, 2005-05-12 at 11:26 -0400, Tom Lane wrote:
I have another idea though: in the case you are looking at, I think
that the context in question never gets any allocations at all, which
means its blocks list stays null. We could move the MemSet inside the
if (blocks) test --- if there are
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
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 changing that? We could introduce additional
contexts or
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
a_ogawa [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
Hmm. It doesn't seem like this could be a big win overall. It's not
possible to save a whole lot of cycles inside AllocSetReset, because if
there isn't anything for it to do, it should fall through pretty quickly
anyway.
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
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 overall. It's not
possible to save a whole lot of cycles
12 matches
Mail list logo
