Re: Re: Request for Patch Feedback: Lag & Lead Window Functions Can Ignore Nulls

From: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
To: Nicholas White <n(dot)j(dot)white(at)gmail(dot)com>
Cc: Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Jeff Davis <pgsql(at)j-davis(dot)com>, Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>, Troels Nielsen <bn(dot)troels(at)gmail(dot)com>, 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" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Re: Request for Patch Feedback: Lag & Lead Window Functions Can Ignore Nulls
Date: 2013-09-30 16:08:18
Message-ID: 20130930160818.GC5235@eldon.alvh.no-ip.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Nicholas White escribió:

> > But even if we did decide to switch memory contexts on every call, it would still be much cleaner than this.
>
> I've removed all the bms_initalize code from the patch and am using
> this solution. As the partition memory is zero-initialised I just
> store a Bitmapset pointer in the WinGetPartitionLocalMemory. The
> bms_add_member and bms_is_member functions behave sensibly for
> null-pointer inputs (they return a bms_make_singleton in the current
> memory context and false respectively). I've surrounded the calls to
> bms_make_singleton with a memory context switch (to the partition's
> context) so the Bitmapset stays in the partition's context.

Now that I look again, would GetMemoryChunkContext() be useful here?

--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David Fetter 2013-09-30 16:29:17 Re: Minmax indexes
Previous Message Peter Eisentraut 2013-09-30 15:37:09 Re: ALTER SYSTEM SET command to change postgresql.conf parameters (RE: Proposal for Allow postgresql.conf values to be changed via SQL [review])