Re: [PATCHES] selecting large result sets in psql using - Mailing list pgsql-hackers

From Jim C. Nasby
Subject Re: [PATCHES] selecting large result sets in psql using
Date
Msg-id 20060824091921.GC73562@pervasive.com
Whole thread Raw
In response to Re: [PATCHES] selecting large result sets in psql using  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [PATCHES] selecting large result sets in psql using
List pgsql-hackers
On Fri, Aug 18, 2006 at 10:16:12AM -0400, Tom Lane wrote:
> Peter Eisentraut <peter_e@gmx.net> writes:
> > A \set variable would make sense to me.
> 
> So Peter and Bruce like a \set variable, Chris and I like a different
> command.  Seems like a tie ... more votes out there anywhere?

If this will be used interactively, it would be nice to have both. That
way if you're running a bunch of cursor fetches, you can just do one
\set, but if you only want to run one or a few you can use \gc and not
mess around with \set. But I don't know how common interactive usage
will be. Presumably code can easily be taught to do either, though \set
would probably be less invasive to older code that someone wants to
change.

Another thought (which probably applies more to \set than \gc): if you
could set a threshold of how many rows the planner is estimating before
automatically switching to a cursor, that would simplify things.
Interactively, you could just let psql/PostgreSQL decide which was best
for each query. Same is true in code, though it probably matters more
for existing code than new code.
-- 
Jim C. Nasby, Sr. Engineering Consultant      jnasby@pervasive.com
Pervasive Software      http://pervasive.com    work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf       cell: 512-569-9461


pgsql-hackers by date:

Previous
From: Markus Schiltknecht
Date:
Subject: Re: Replication
Next
From: Gregory Stark
Date:
Subject: Re: Tricky bugs in concurrent index build