Re: [HACKERS] [PATCHES] selecting large result sets in psql using cursors

2006-08-17 Thread Peter Eisentraut
Tom Lane wrote: BTW, \u seems not to have any mnemonic value whatsoever ... isn't there some other name we could use? Ever since pgsql-patches replies started going to -hackers, threading doesn't work anymore, so I for one can't tell what this refers to at all. -- Peter Eisentraut

Re: [HACKERS] [PATCHES] selecting large result sets in psql using

2006-08-17 Thread Bruce Momjian
Peter Eisentraut wrote: Tom Lane wrote: BTW, \u seems not to have any mnemonic value whatsoever ... isn't there some other name we could use? Ever since pgsql-patches replies started going to -hackers, threading doesn't work anymore, so I for one can't tell what this refers to at all.

Re: [HACKERS] [PATCHES] selecting large result sets in psql using

2006-08-17 Thread Simon Riggs
On Thu, 2006-08-17 at 03:14 -0400, Bruce Momjian wrote: Peter Eisentraut wrote: Tom Lane wrote: BTW, \u seems not to have any mnemonic value whatsoever ... isn't there some other name we could use? Ever since pgsql-patches replies started going to -hackers, threading doesn't work

Re: [PATCHES] CREATE INDEX ... ONLINE

2006-08-17 Thread Greg Stark
Greg Stark [EMAIL PROTECTED] writes: Tom Lane [EMAIL PROTECTED] writes: Greg Stark [EMAIL PROTECTED] writes: Updated patch. Fixed a few minor things, added documentation and regression tests. Unfortunately I can't test the regression tests because I get a segmentation fault

Re: [PATCHES] CREATE INDEX ... ONLINE

2006-08-17 Thread Tom Lane
Greg Stark [EMAIL PROTECTED] writes: Just remembered one open question I had. I'm not clear what to do with the index statistics. It may be that the current code is basically the right thing -- it leaves the statistics as they are after phase 1, ie after the regular index build before we go

Re: [PATCHES] selecting large result sets in psql using cursors

2006-08-17 Thread Chris Mair
Hi, thanks for reviewing this :) attached is the new and fixed version of the patch for selecting large result sets from psql using cursors. The is_select_command bit is wrong because it doesn't allow for left parentheses in front of the SELECT keyword (something entirely reasonable

[PATCHES] Autovacuum maintenance window (was Re: Adjust autovacuum naptime automatically)

2006-08-17 Thread Alvaro Herrera
Matthew T. O'Connor wrote: My vision of the maintenance window has always been very simple, that is, during the maintenance window the thresholds get reduced by some factor (probably a GUC variable) so during the day it might take 1 updates on a table to cause a vacuum but during the

Re: [PATCHES] [HACKERS] Autovacuum maintenance window (was Re: Adjust autovacuum

2006-08-17 Thread Matthew T. O'Connor
Alvaro Herrera wrote: My vision is a little more complex than that. You define group of tables, and separately you define time intervals. For each combination of group and interval you can configure certain parameters, like a multiplier for the autovacuum thresholds and factors; and also the

Re: [HACKERS] [PATCHES] selecting large result sets in psql using

2006-08-17 Thread Bruce Momjian
Chris Mair wrote: At some point we ought to extend libpq enough to expose the V3-protocol feature that allows partial fetches from portals; that would be a cleaner way to implement this feature. However since nobody has yet proposed a good API for this in libpq, I don't object to

Re: [HACKERS] [PATCHES] selecting large result sets in psql using

2006-08-17 Thread Chris Mair
Replying to myself... Patch with fix against current CVS is attached. Alvaro Herrera sent two fixes off-list: a typo and at the end of SendQueryUsingCursor I sould COMMIT, not ROLLBACK. So, one more version (6) that fixes these too is attached. Bye, Chris. PS: I'm keeping this on both lists

Re: [HACKERS] [PATCHES] selecting large result sets in psql using

2006-08-17 Thread Chris Mair
Patch with fix against current CVS is attached. Forgot the attachment... soory. -- Chris Mair http://www.1006.org diff -rc pgsql.original/doc/src/sgml/ref/psql-ref.sgml pgsql/doc/src/sgml/ref/psql-ref.sgml *** pgsql.original/doc/src/sgml/ref/psql-ref.sgml 2006-08-17 16:50:58.0

Re: [HACKERS] [PATCHES] selecting large result sets in psql using

2006-08-17 Thread Chris Mair
BTW, \u seems not to have any mnemonic value whatsoever ... isn't there some other name we could use? True :) Since buffer commands all have a single char I wanted a single char one too. The c for cursor was taken already, so i choose the u (second char in cursor). If somebody

Re: [HACKERS] [PATCHES] selecting large result sets in psql using

2006-08-17 Thread Bruce Momjian
Chris Mair wrote: BTW, \u seems not to have any mnemonic value whatsoever ... isn't there some other name we could use? True :) Since buffer commands all have a single char I wanted a single char one too. The c for cursor was taken already, so i choose the u (second char

Re: [HACKERS] [PATCHES] selecting large result sets in psql using cursors

2006-08-17 Thread Tom Lane
Bruce Momjian [EMAIL PROTECTED] writes: Chris Mair wrote: Since buffer commands all have a single char I wanted a single char one too. The c for cursor was taken already, so i choose the u (second char in cursor). If somebody has a better suggestion, let us know ;) I think a new backslash

Re: [HACKERS] [PATCHES] selecting large result sets in psql using

2006-08-17 Thread Bruce Momjian
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: Chris Mair wrote: Since buffer commands all have a single char I wanted a single char one too. The c for cursor was taken already, so i choose the u (second char in cursor). If somebody has a better suggestion, let us know ;) I

Re: [HACKERS] [PATCHES] selecting large result sets in psql using

2006-08-17 Thread Chris Mair
Since buffer commands all have a single char I wanted a single char one too. The c for cursor was taken already, so i choose the u (second char in cursor). If somebody has a better suggestion, let us know ;) I think a new backslash variable isn't the way to go. I would use a