Skip site navigation (1) Skip section navigation (2)

Re: Analysis Function

From: Tim Landscheidt <tim(at)tim-landscheidt(dot)de>
To: pgsql-performance(at)postgresql(dot)org
Subject: Re: Analysis Function
Date: 2010-06-11 11:18:37
Message-ID: m3typ9hl6a.fsf@passepartout.tim-landscheidt.de (view raw or flat)
Thread:
Lists: pgsql-performance
David Jarvis <thangalin(at)gmail(dot)com> wrote:

>> Have you tested DATE_TRUNC()?

> Not really; it returns a full timestamp and I would still have to
> concatenate strings. My goal is to speed up the following code (where
> *p_*parameters are user inputs):

> *        date(extract(YEAR FROM m.taken)||''-'||p_month1||'-'||p_day1||''')
> d1,
>         date(extract(YEAR FROM m.taken)||''-'||p_month2||'-'||p_day2||''')
> d2*

> Using DATE_TRUNC() won't help here, as far as I can tell. Removing the
> concatenation will halve the query's time. Such as:

> dateserial( m.taken, p_month1, p_day1 ) d1,
> dateserial( m.taken, p_month2, p_day2 ) d2

> My testing so far has shown a modest improvement by using a C function (to
> avoid concatenation).

You could use:

| (DATE_TRUNC('year', m.taken) + p_month1 * '1 month'::INTERVAL + p_day1 * '1 day'::INTERVAL)::DATE

but whether that is faster or slower I don't know. But I
don't see why this query needs to be fast in the first
place. It seems to be interactive, and therefore I wouldn't
invest too much time to have the user wait not 4.4, but
2.2 seconds. You could also do the concatenation in the ap-
plication if that is faster than PostgreSQL's date arithme-
tics.

Tim


In response to

Responses

pgsql-performance by date

Next:From: Kenneth MarshallDate: 2010-06-11 12:44:24
Subject: Re: slow query performance
Previous:From: Jayadevan MDate: 2010-06-11 09:56:09
Subject: Query about index usage

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group