From: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
---|---|
To: | David Jarvis <thangalin(at)gmail(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-performance(at)postgresql(dot)org, Magnus Hagander <magnus(at)hagander(dot)net> |
Subject: | Re: Analysis Function |
Date: | 2010-06-13 06:02:23 |
Message-ID: | 4C14746F.9050603@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On 11/06/10 23:38, David Jarvis wrote:
> I added an explicit cast in the SQL:
>
> dateserial(extract(YEAR FROM
> m.taken)::int,'||p_month1||','||p_day1||') d1,
> dateserial(extract(YEAR FROM
> m.taken)::int,'||p_month2||','||p_day2||') d2
>
> The function now takes three integer parameters; there was no performance
> loss.
We had a little chat about this with Magnus. It's pretty surprising that
there's no built-in function to do this, we should consider adding one.
We could have a function like:
construct_timestamp(year int4, month int4, date int4, hour int4, minute
int4, second int4, milliseconds int4, timezone text)
Now that we have named parameter notation, callers can use it to
conveniently fill in only the fields needed:
SELECT construct_timestamp(year := 1999, month := 10, date := 22);
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | David Jarvis | 2010-06-13 07:38:48 | Re: Analysis Function |
Previous Message | Bruce Momjian | 2010-06-13 01:08:17 | Re: [PERFORM] Large (almost 50%!) performance drop after upgrading to 8.4.4? |