Tom Lane wrote:
> Bruce Momjian 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, would you run test
Tom Lane wrote:
> Bruce Momjian 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 out of CVS.
--
Bruce Momjian 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.
regards, tom lane
---(end
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 major
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.
---
a_
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
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 ther
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:
> >> 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 inc
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
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
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
