From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
---|---|
To: | Nicholas White <n(dot)j(dot)white(at)gmail(dot)com> |
Cc: | Hitoshi Harada <umi(dot)tanuki(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Request for Patch Feedback: Lag & Lead Window Functions Can Ignore Nulls |
Date: | 2013-06-15 20:30:50 |
Message-ID: | 1371328250.26438.13.camel@jdavis |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sun, 2013-03-24 at 20:15 -0400, Nicholas White wrote:
> I've redone the leadlag function changes to use datumCopy as you
> suggested. However, I've had to remove the NOT_USED #ifdef around
> datumFree so I can use it to avoid building up large numbers of copies
> of Datums in the memory context while a query is executing. I've
> attached the revised patch...
>
Comments:
WinGetResultDatumCopy() calls datumCopy, which will just copy in the
current memory context. I think you want it in the per-partition memory
context, otherwise the last value in each partition will stick around
until the query is done (so many partitions could be a problem). That
should be easy enough to do by switching to the
winobj->winstate->partcontext memory context before calling datumCopy,
and then switching back.
For that matter, why store the datum again at all? You can just store
the offset of the last non-NULL value in that partition, and then fetch
it using WinGetFuncArgInPartition(), right? We really want to avoid any
per-tuple allocations.
Alternatively, you might look into setting a mark when you get a
non-NULL value. Then you could just always fetch the oldest one.
Unfortunately, I think that only works with const_offset=true... so the
previous idea might be better.
I'll leave it to someone else to review the grammar changes.
Regards,
Jeff Davis
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2013-06-15 21:31:15 | Re: Patch for fail-back without fresh backup |
Previous Message | Simon Riggs | 2013-06-15 20:30:21 | Re: Add visibility map information to pg_freespace. |