with this (lots...:)
Bye, Chris.
--
Chris Mair
http://www.1006.org
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
, consistently.
If we find we can't live with the performance overhead of that
if(FETCH_COUNT), it is still not clear why we would be better
off moving it into the \g code path only.
Is it because presumably \g is used less often in existing psql scripts?
Bye, Chris.
--
Chris Mair
http://www.1006
a single char I wanted a single char one
too. The c for cursor was taken already, so i choose the u (second
char in cursor). If somebody has a better suggestion, let us know ;)
Bye, Chris.
PS: I'm traveling Fri 18th - Fri 25th and won't check mail often.
--
Chris Mair
http://www.1006.org
diff
now, hope it's ok.
--
Chris Mair
http://www.1006.org
---(end of broadcast)---
TIP 6: explain analyze is your friend
Patch with fix against current CVS is attached.
Forgot the attachment... soory.
--
Chris Mair
http://www.1006.org
diff -rc pgsql.original/doc/src/sgml/ref/psql-ref.sgml pgsql/doc/src/sgml/ref/psql-ref.sgml
*** pgsql.original/doc/src/sgml/ref/psql-ref.sgml 2006-08-17 16:50:58.0
to existing code paths. Also the other \pset options are somewhat
orthogonal to this one. Just my two EUR cents, of course... :)
Bye, Chris.
--
Chris Mair
http://www.1006.org
---(end of broadcast)---
TIP 4: Have you searched our list archives
it as a modifyer to \g? Yea, that works, but it doesn't work for
';' as a 'go' command, of course, which is perhaps OK.
Yes, it was intended to differentiate this command from ';';
Bye, Chris.
--
Chris Mair
http://www.1006.org
---(end of broadcast
Hi there,
attached is the new and fixed version of the patch for selecting
large result sets from psql using cursors.
It was previously discussed on hackers:
http://archives.postgresql.org/pgsql-hackers/2006-07/msg00231.php
Thanks again to Neil Conway for helping with this (the first
sketch of
