Re: [PATCHES] updated patch for selecting large results sets in - Mailing list pgsql-hackers

From Chris Mair
Subject Re: [PATCHES] updated patch for selecting large results sets in
Date
Msg-id 1156792650.4026.34.camel@dell.home.lan
Whole thread Raw
In response to Re: [PATCHES] updated patch for selecting large results sets in psql using cursors  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [PATCHES] updated patch for selecting large results
List pgsql-hackers
On Mon, 2006-08-28 at 13:45 -0400, Tom Lane wrote:
> Peter Eisentraut <peter_e@gmx.net> 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

Hi,

after agreeing on using a \set variable, I proposed to have it influence
"\g" as well as ";", because I thought that would be the most expected
behaviour. IMHO I'm with Peter, that introducing a difference between
"\g" and ";" would go against the principle of least surprise.

Performance-wise I took for granted without checking that GetVariable's
running time would be negligible.

[looks at the code]

I see it's it's basically two function calls with a loop over a linked
list of values (in the order of 10) doing strcmps and one strtol.
It is not quite clear to me what the impact of this is. I could
imagine it would show up only if you perform lots of trivial queries
through psql. I'm going to benchmark something now and report back.

Anyway, regardless the benchmark, I feel it's somehow not clean to have
a variable introduce a difference between "\g" and ";".

[goes benchmarking...]

Bye, Chris.


-- 

Chris Mair
http://www.1006.org




pgsql-hackers by date:

Previous
From: "Alon Goldshuv"
Date:
Subject: Unnecessary rescan for non scrollable holdable cursors
Next
From: Tom Lane
Date:
Subject: Re: autovacuum causing numerous regression-test failures