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

Reply via email to