From: | "Adnan DURSUN" <a_dursun(at)hotmail(dot)com> |
---|---|
To: | <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: SQL Function Performance |
Date: | 2006-02-14 22:35:59 |
Message-ID: | BAY106-DAV244F7CACF7398D74C15861FA060@phx.gbl |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
-------Original Message-------
From: Michael Fuhr
Date: 02/14/06 23:05:55
To: Adnan DURSUN
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: [PERFORM] SQL Function Performance
>On Tue, Feb 14, 2006 at 11:33:57AM +0200, Adnan DURSUN wrote:
>> -> Nested Loop (cost=5.90..267.19 rows=3 width=101) (actual time=76.240..30974.777 rows=63193 loops=1)
>> -> Nested Loop (cost=5.90..123.48 rows=26 width=73) (actual time=32.082..4357.786 rows=14296 loops=1)
>Absent a better solution, you could write a PL/pgSQL function and
>build the query as a text string, then EXECUTE it. That would give
>you a new plan each time, one that can take better advantage of
>statistics, at the cost of having to plan the query each time you
>call the function (but you probably don't care about that cost
>as long as the overall results are better). Here's an example:
Yes, i did it. i wrote a PL/pgSQL function. Now results come at 100 ms.. :-)
I dont like that method but i have to do it for perfomance....
Many thanks to everyone who helps...
Adnan DURSUN
ASRIN Bilisim Ltd.
Ankara /TURKEY
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
From | Date | Subject | |
---|---|---|---|
Next Message | Aaron Turner | 2006-02-14 23:14:03 | Re: 10+hrs vs 15min because of just one index |
Previous Message | Tom Lane | 2006-02-14 22:15:41 | Re: 0ut of Memory Error during Vacuum Analyze and Create Index |