Received: from makus.postgresql.org (makus.postgresql.org [98.129.198.125])
	by mail.postgresql.org (Postfix) with ESMTP id 117FE1AEBA96
	for <pgsql-performance@postgresql.org>;
	Tue, 24 Jan 2012 17:11:33 -0400 (AST)
Received: from 97-64-237-59.client.mchsi.com ([97.64.237.59]
	helo=marajade.localdomain)
	by makus.postgresql.org with esmtp (Exim 4.72)
	(envelope-from <andy@squeakycode.net>) id 1RpneL-00025a-2Q
	for pgsql-performance@postgresql.org; Tue, 24 Jan 2012 21:11:33 +0000
Received: from [192.168.10.84] (unknown [192.168.10.84])
	(Authenticated sender: andy)
	by marajade.localdomain (Postfix) with ESMTPA id 5EB764A2E2;
	Tue, 24 Jan 2012 15:11:16 -0600 (CST)
Message-ID: <4F1F1E7A.4080403@squeakycode.net>
Date: Tue, 24 Jan 2012 15:11:22 -0600
From: Andy Colson <andy@squeakycode.net>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0.1
MIME-Version: 1.0
To: Tony Capobianco <tcapobianco@prospectiv.com>
CC: Pavel Stehule <pavel.stehule@gmail.com>, pgsql-performance@postgresql.org
Subject: Re: Cursor fetch performance issue
References: <1327437700.1968.10.camel@tony1.localdomain>
	<CAFj8pRD3g3WESOxES27t_pBh_30Ko7JO7nKCf77oRsjU==tFwQ@mail.gmail.com>
	<1327438657.1968.15.camel@tony1.localdomain>
In-Reply-To: <1327438657.1968.15.camel@tony1.localdomain>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Pg-Spam-Score: -0.9 (/)
X-Archive-Number: 201201/65
X-Sequence-Number: 46077

> On Tue, 2012-01-24 at 21:47 +0100, Pavel Stehule wrote:
>> Hello
>>
>> 2012/1/24 Tony Capobianco<tcapobianco@prospectiv.com>:
>>> We are migrating our Oracle warehouse to Postgres 9.
>>>
>>> This function responds well:
>>>
>>> pg=# select public.getMemberAdminPrevious_sp2(247815829, 1,'test.email@hotmail.com', 'email', 'test');
>>>   getmemberadminprevious_sp2
>>> ----------------------------
>>>   <unnamed portal 1>
>>> (1 row)
>>>
>>> Time: 7.549 ms
>>>
>>> However, when testing, this fetch takes upwards of 38 minutes:
>>>
>>> BEGIN;
>>> select public.getMemberAdminPrevious_sp2(247815829, 1,'test.email@hotmail.com', 'email', 'test');
>>> FETCH ALL IN "<unnamed portal 2>";
>>>
>>> How can I diagnose any performance issues with the fetch in the cursor?
>>>
>>
>> Cursors are optimized to returns small subset of result - if you plan
>> to read complete result, then set
>>
>> set cursor_tuple_fraction to 1.0;
>>
>> this is session config value, you can set it before selected cursors queries
>>
>> Regards
>>
>> Pavel Stehule
>>
>>> Thanks.
>>> Tony
>>>
>>>
>>> --
>>> Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
>>> To make changes to your subscription:
>>> http://www.postgresql.org/mailpref/pgsql-performance
>>
>
>
>


On 1/24/2012 2:57 PM, Tony Capobianco wrote:
 > Running just the sql of the function returns only 10 rows:
 >
 > pg=# SELECT m.memberid, m.websiteid, m.emailaddress,
 > pg-#                m.firstname, m.lastname, m.regcomplete, m.emailok
 > pg-#         FROM   members m
 > pg-#         WHERE  m.emailaddress LIKE 'test.email@hotmail.com'
 > pg-#         AND    m.changedate_id<  5868 ORDER BY m.emailaddress, 
m.websiteid;
 >   memberid  | websiteid |    emailaddress        | firstname | 
lastname | regcomplete | emailok
 > 
-----------+-----------+------------------------+-----------+----------+-------------+---------
 >   247815829 |         1 | test.email@hotmail.com | email     | test 
    |           1 |       1
 >   300960335 |        62 | test.email@hotmail.com |           | 
    |           1 |       1
 >   300959937 |       625 | test.email@hotmail.com |           | 
    |           1 |       1
 >   260152830 |      1453 | test.email@hotmail.com |           | 
    |           1 |       1
 >   300960163 |      1737 | test.email@hotmail.com | email     | test 
    |           1 |       1
 >   300960259 |      1824 | test.email@hotmail.com | email     | test 
    |           1 |       1
 >   300959742 |      1928 | test.email@hotmail.com | email     | test 
    |           1 |       1
 >   368122699 |      2457 | test.email@hotmail.com | email     | test 
    |           1 |       1
 >   403218613 |      2464 | test.email@hotmail.com | email     | test 
    |           1 |       0
 >   378951994 |      2656 | test.email@hotmail.com |           | 
    |           1 |       1
 > (10 rows)
 >
 > Time: 132.626 ms
 >
 > So, it would seem that's a small enough number of rows. 
Unfortunately, issuing:
 >
 > set cursor_tuple_fraction to 1.0;
 >
 > Did not have an effect on performance.  Is it common to modify this
 > cursor_tuple_fraction parameter each time we execute the function?
 >
 >


So, is getMemberAdminPrevious_sp2() preparing a statement with wildcards?

SELECT m.memberid, m.websiteid, m.emailaddress,
        m.firstname, m.lastname, m.regcomplete, m.emailok
        FROM   members m
        WHERE  m.emailaddress LIKE $1
        AND    m.changedate_id < $2
       ORDER BY m.emailaddress, m.websiteid;

Or is it creating the string and executing it:

sql = 'SELECT m.memberid, m.websiteid, m.emailaddress, '
     ||  ' m.firstname, m.lastname, m.regcomplete, m.emailok '
     ||  ' FROM   members m
     ||  ' WHERE  m.emailaddress LIKE ' || arg1
     ||  ' AND    m.changedate_id < ' || arg2
     ||  ' ORDER BY m.emailaddress, m.websiteid ';
execute(sql);

Maybe its the planner doesnt plan so well with $1 arguments vs actual 
arguments thing.

-Andy