Re: [HACKERS] ECPG regression failures on OpenBSD
> Michael, if you want shell access to guppy, just contact me privately. > Warning: guppy too, is somewhat dated (1:10 hours for the make step) :/ Michael, did you receive my private mail yesterday? (just want to make sure it wasn't blocked by an overzealous spam filter) Bye, Chris. -- Chris Mair http://www.1006.org ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] selecting large result sets in psql using
>>> To cut the Gordon knot I'm going to suggest we use: >> >>> \set CURSOR_FETCH fetch_count >> >>> and \g and ; are modified such that when they see >>> this variable set to fetch_count > 0 and the buffer >>> is a select they would use the modified fetch/output code. >> >>> Does this sound reasonable to everyone? >> >> OK with me, but maybe call the variable FETCH_COUNT, to avoid the >> presupposition that the implementation uses a cursor. As I mentioned >> before, I expect we'll someday rework it to not use that. >> >> regards, tom lane > > Ok, > sounds good. > I'm travelling this week, but can send an updated patch during the > weekend. I've just submitted an updated patch to pgsql-patches in a new thread :) Bye, Chris. -- Chris Mair http://www.1006.org ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [PATCHES] selecting large result sets in psql using
> 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. I don't know if having both is really that desirable. In particular, as Peter pointed out, \gc is not possible because it means \g outputting to file 'c' in the current version of psql. > 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. Right now, this would be very hard, because the existing output code cannot readily be adapted to using cursors. My patch does fetching and output in a new code path that is very simple, but doesn't do all the nice formatting for human readability. So moving seamlessly between the two behind the scenes is not possible, least refactoring the whole output code of psql. Tom Lane mentioned the solution at the root of all this eventually might be a new version of libpq that does large fetches in chunks on its own. But, we're talking > 8.2.0 then... Bye :) Chris. -- Chris Mair http://www.1006.org ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] [PATCHES] selecting large result sets in psql using
>> To cut the Gordon knot I'm going to suggest we use: > >> \set CURSOR_FETCH fetch_count > >> and \g and ; are modified such that when they see >> this variable set to fetch_count > 0 and the buffer >> is a select they would use the modified fetch/output code. > >> Does this sound reasonable to everyone? > > OK with me, but maybe call the variable FETCH_COUNT, to avoid the > presupposition that the implementation uses a cursor. As I mentioned > before, I expect we'll someday rework it to not use that. > > regards, tom lane Ok, sounds good. I'm travelling this week, but can send an updated patch during the weekend. Bye, Chris. -- Chris Mair http://www.1006.org ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] [PATCHES] selecting large result sets in psql using
>> True. They could even put it in .psqlrc if they want. Basically need >> a way to modify \g. Seems a \set is the way we have always done such >> modifications in the past. The big question is whether this is >> somehow different. Personally, I don't think so. > > If you want a \set variable, then at least make it do something useful: > make it an integer var that sets the fetch count, rather than > hard-wiring the count as is done in Chris' existing patch. Zero (or > perhaps unset) disables. > > regards, tom lane Hello, first I must admit that I misunderstood Bruce post. I thought he meant to tweak \pset (psql command to set formatting). This didn't make sense to me. Only now I realize everyone is talking about \set (psql internal variable). That being said, I'm a bit unsure now what we should do. As Peter said, it is true that mostly this feature would be used for scripting where \set and \unset are not as cumbersome to use as in an interactive session. Tom's idea to factor in the fetch count as an option is also very tempting. To cut the Gordon knot I'm going to suggest we use: \set CURSOR_FETCH fetch_count and \g and ; are modified such that when they see this variable set to fetch_count > 0 and the buffer is a select they would use the modified fetch/output code. Does this sound reasonable to everyone? Bye :) Chris. -- Chris Mair http://www.1006.org ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
