| From: | Merlin Moncure <mmoncure(at)gmail(dot)com> | 
|---|---|
| To: | Paul A Jungwirth <pj(at)illuminatedcomputing(dot)com> | 
| Cc: | sudalai <sudalait2(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> | 
| Subject: | Re: First Aggregate Funtion? | 
| Date: | 2015-07-20 18:28:55 | 
| Message-ID: | CAHyXU0xKQhrqwimGvQ8b3CvrZjWMye0r+pay_50RUBc+SFfbMw@mail.gmail.com | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-hackers | 
On Mon, Jul 20, 2015 at 10:06 AM, Paul A Jungwirth
<pj(at)illuminatedcomputing(dot)com> wrote:
>> The above implementation of "first" aggregate returns the first non-NULL item
>> value.
>
> I'm curious what advantages this approach has over these FIRST/LAST
> functions from the Wiki?:
>
>     https://wiki.postgresql.org/wiki/First/last_%28aggregate%29
>
> Also to get the "first non-null value" you can apply an ordering to
> just the aggregate function, e.g.:
>
>     select first(id order by start_time nulls last) from events;
>
> If you want speed you should probably write a C version.
C functions come with a lot of administration headaches, and the
performance gain will probably not be significant unless you totally
bypass the SPI interface.   Even then, I suspect (vs the pl/pgsql
variant which caches plan) the majority of overhead is is in calling
the function, not the actual implementation.  It's be interesting to
see the results though.
merlin
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Heikki Linnakangas | 2015-07-20 20:23:41 | Re: All-zero page in GIN index causes assertion failure | 
| Previous Message | Tom Lane | 2015-07-20 17:48:48 | Re: [BUGS] object_classes array is broken, again |