2012/1/24 Tony Capobianco <[email protected]>:
> 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 '[email protected]'
> pg-# AND m.changedate_id < 5868 ORDER BY m.emailaddress,
> m.websiteid;
> memberid | websiteid | emailaddress | firstname | lastname |
> regcomplete | emailok
> -----------+-----------+------------------------+-----------+----------+-------------+---------
> 247815829 | 1 | [email protected] | email | test |
> 1 | 1
> 300960335 | 62 | [email protected] | | |
> 1 | 1
> 300959937 | 625 | [email protected] | | |
> 1 | 1
> 260152830 | 1453 | [email protected] | | |
> 1 | 1
> 300960163 | 1737 | [email protected] | email | test |
> 1 | 1
> 300960259 | 1824 | [email protected] | email | test |
> 1 | 1
> 300959742 | 1928 | [email protected] | email | test |
> 1 | 1
> 368122699 | 2457 | [email protected] | email | test |
> 1 | 1
> 403218613 | 2464 | [email protected] | email | test |
> 1 | 0
> 378951994 | 2656 | [email protected] | | |
> 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?
>
no, usually only before some strange query. Check execution plan,
please - but I don't think so your slow query depends on cursor usage.
postgres=# set cursor_tuple_fraction TO 1.0;
SET
postgres=# explain declare x cursor for select * from foo where a % 2
= 0 order by a;
QUERY PLAN
────────────────────────────────────────────────────────────────
Sort (cost=19229.19..19241.69 rows=5000 width=4)
Sort Key: a
-> Seq Scan on foo (cost=0.00..18922.00 rows=5000 width=4)
Filter: ((a % 2) = 0)
(4 rows)
postgres=# set cursor_tuple_fraction TO 1.0;
SET
postgres=# explain declare x cursor for select * from foo where a % 2
= 0 order by a;
QUERY PLAN
────────────────────────────────────────────────────────────────
Sort (cost=19229.19..19241.69 rows=5000 width=4)
Sort Key: a
-> Seq Scan on foo (cost=0.00..18922.00 rows=5000 width=4)
Filter: ((a % 2) = 0)
(4 rows)
postgres=# set cursor_tuple_fraction TO 0.1;
SET
postgres=# explain declare x cursor for select * from foo where a % 2
= 0 order by a;
QUERY PLAN
───────────────────────────────────────────────────────────────────────────
Index Scan using foo_pkey on foo (cost=0.00..32693.34 rows=5000 width=4)
Filter: ((a % 2) = 0)
(2 rows)
Regards
Pavel Stehule
>
> On Tue, 2012-01-24 at 21:47 +0100, Pavel Stehule wrote:
>> Hello
>>
>> 2012/1/24 Tony Capobianco <[email protected]>:
>> > We are migrating our Oracle warehouse to Postgres 9.
>> >
>> > This function responds well:
>> >
>> > pg=# select public.getMemberAdminPrevious_sp2(247815829,
>> > 1,'[email protected]', '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,'[email protected]', '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 ([email protected])
>> > To make changes to your subscription:
>> > http://www.postgresql.org/mailpref/pgsql-performance
>>
>
>
--
Sent via pgsql-performance mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
