On Sat, 2006-07-15 at 21:10 -0400, Greg Stark wrote: > Hannu Krosing <[EMAIL PROTECTED]> writes:
> > Another related thing - throttling > > ---------------------------------- > > > > Did you do any work on using vacuum_cost_* GUC vars to throttle the > > build process if desired ? > > Actually no. While there is consensus that will be necessary I'm not sure I > can do it with this patch. The problem is that most of the real heavy lifting > here is done inside tuplesort. Even aside from that most of what's left is > inside bulkdelete(*) and the code that handles regular index builds. > > So I think we'll need some global thinking about what options Postgres needs > to control throttling in general. And probably someone needs to write a > separate patch that adds all the hooks to the various places in a single go. > Trying to throttle just one operation at a time when a lot of the code that > implements these operations is shared will have us running in circles. > > (*) Hm. Come to think of it I wonder if the vacuum_cost parameters are already > kicking in for this phase. That would be a bit strange since it's the fastest > of the three scans. Separate patches sounds more sensible. Using statement_cost_* in many places sounds useful to me and not too hard to get into 8.2 -- Simon Riggs EnterpriseDB http://www.enterprisedb.com ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend
