On Sat, 2006-07-15 at 21:10 -0400, Greg Stark wrote:
> Hannu Krosing <hannu@skype.net> 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
