Re: [HACKERS] [PATCHES] updated patch for selecting large results sets in psql using cursors

2006-08-29 Thread Tom Lane
[EMAIL PROTECTED] writes:
 here comes the latest version (version 7) of the patch to handle large
 result sets with psql.  As previously discussed, a cursor is used
 for SELECT queries when \set FETCH_COUNT some_value  0

Applied with revisions ... I didn't like the fact that the code was
restricted to handle only unaligned output format, so I fixed print.c
to be able to deal with emitting output in sections.  This is not
ideal for aligned output mode, because we compute column widths
separately for each FETCH group, but all the other output modes work
nicely.  I also did a little hacking to make \timing and pager output
work as expected.

regards, tom lane

---(end of broadcast)---
TIP 4: Have you searched our list archives?

   http://archives.postgresql.org


Re: [HACKERS] [PATCHES] updated patch for selecting large results sets in psql using cursors

2006-08-28 Thread Tom Lane
Peter Eisentraut [EMAIL PROTECTED] writes:
 Tom Lane wrote:
 Wait a minute.  What I thought we had agreed to was a patch to make
 commands sent with \g use a cursor.  This patch changes SendQuery
 so that *every* command executed via psql is treated this way.

 That's what I remembered.  I don't think we want to introduce a 
 difference between ; and \g.

Have we measured the performance impact, then?  The last time I profiled
psql, GetVariable was already a hotspot, and this introduces another
call of it into the basic query loop whether you use the feature or not.

regards, tom lane

---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faq


Re: [HACKERS] [PATCHES] updated patch for selecting large results sets in psql using cursors

2006-08-28 Thread Tom Lane
[EMAIL PROTECTED] writes:
 here comes the latest version (version 7) of the patch to handle large
 result sets with psql.  As previously discussed, a cursor is used
 for SELECT queries when \set FETCH_COUNT some_value  0

Wait a minute.  What I thought we had agreed to was a patch to make
commands sent with \g use a cursor.  This patch changes SendQuery
so that *every* command executed via psql is treated this way.
That's a whole lot bigger behavioral change than I think is warranted.

regards, tom lane

---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
   choose an index scan if your joining column's datatypes do not
   match


Re: [HACKERS] [PATCHES] updated patch for selecting large results sets in psql using cursors

2006-08-28 Thread Peter Eisentraut
Tom Lane wrote:
 Wait a minute.  What I thought we had agreed to was a patch to make
 commands sent with \g use a cursor.  This patch changes SendQuery
 so that *every* command executed via psql is treated this way.

That's what I remembered.  I don't think we want to introduce a 
difference between ; and \g.

-- 
Peter Eisentraut
http://developer.postgresql.org/~petere/

---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster


Re: [HACKERS] [PATCHES] updated patch for selecting large results sets in psql using cursors

2006-08-28 Thread Tom Lane
Bruce Momjian [EMAIL PROTECTED] writes:
 Peter Eisentraut wrote:
 Tom Lane wrote:
 Wait a minute.  What I thought we had agreed to was a patch to make
 commands sent with \g use a cursor.

 I am confused.  I assume \g and ; should be affected, like Peter says. 
 Tom, what *every* command are you talking about?  You mean \d?

Like I said, I thought we were intending to modify \g's behavior only;
that was certainly the implication of the discussion of \gc.

regards, tom lane

---(end of broadcast)---
TIP 4: Have you searched our list archives?

   http://archives.postgresql.org