Re: [PATCHES] updated patch for selecting large results sets in psql using cursors
<[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 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] updated patch for selecting large results sets
Tom Lane wrote: > Bruce Momjian <[EMAIL PROTECTED]> writes: > > OK, got it. I just don't see the value to doing \g and not ;. I think > > the \gc case was a hack when he didn't have \set. Now that we have > > \set, we should be consistent. > > I'm willing to accept this if we can make sure we aren't adding any > overhead --- see my proposal elsewhere in the thread for fixing that. Right, if \g has overhead, I don't want people to start using ; because it is faster. That is the kind of behavior that makes us look sloppy. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] updated patch for selecting large results sets in
> > > 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". At some point you OKed the "\g and ;" proposal. I admit I was quick adding the "and ;" part, but it seemed so natural once we agreed on using a variable. > OK, got it. I just don't see the value to doing \g and not ;. I think > the \gc case was a hack when he didn't have \set. Now that we have > \set, we should be consistent. I agree with this statement. If we have a variable that switches just between two versions of \g, we could have gone with using \u (or whatever) in the first place. In the mean time I have been converted by the variable camp, and I think the variable should change "\g" and ";" together, 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.org ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] updated patch for selecting large results sets
Bruce Momjian <[EMAIL PROTECTED]> writes: > OK, got it. I just don't see the value to doing \g and not ;. I think > the \gc case was a hack when he didn't have \set. Now that we have > \set, we should be consistent. I'm willing to accept this if we can make sure we aren't adding any overhead --- see my proposal elsewhere in the thread for fixing that. regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] updated patch for selecting large results sets
Tom Lane wrote: > 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". OK, got it. I just don't see the value to doing \g and not ;. I think the \gc case was a hack when he didn't have \set. Now that we have \set, we should be consistent. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] updated patch for selecting large results sets in psql using cursors
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 2: Don't 'kill -9' the postmaster
Re: [PATCHES] updated patch for selecting large results sets
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. 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. I am confused. I assume \g and ; should be affected, like Peter says. Tom, what *every* command are you talking about? You mean \d? -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] updated patch for selecting large results sets in psql using cursors
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 6: explain analyze is your friend
Re: [PATCHES] updated patch for selecting large results sets in psql using cursors
<[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 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
