"Steven McLellan" <smclellan(at)mintel(dot)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