"Steven McLellan" <smclel...@mintel.com> writes: > I've found what appears to be a bug seriously affecting performance running > a particular query using a named cursor versus running it as a simple > SELECT.
You haven't shown us a plan for the cursor case, but I'm thinking the issue here is that Postgres prefers fast-start plans for cursors, on the theory that if you're using a cursor you probably care more about incremental fetching than the total elapsed time. As of 8.4 you can twiddle the strength of that preference via cursor_tuple_fraction. http://www.postgresql.org/docs/8.4/static/runtime-config-query.html#GUC-CURSOR-TUPLE-FRACTION regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
