<[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
res
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 ar
> > > 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
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 ---
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 sa
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* comma
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
Chris Mair <[EMAIL PROTECTED]> writes:
> The conclusion is that, yes, the overhead is measurable, albeit with
> a very synthetic benchmark (of the type MySQL wins ;).
OK, so about 3 or 4% overhead added to extremely short queries.
That's not enough to kill this patch, but it's still annoying ...
a
On Mon, 2006-08-28 at 13:45 -0400, Tom Lane wrote:
> 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 execu
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.
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 bet
<[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
com
12 matches
Mail list logo
