From: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
---|---|
To: | Greg Stark <gsstark(at)mit(dot)edu> |
Cc: | Hannu Krosing <hannu(at)skype(dot)net>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Online index builds |
Date: | 2006-07-16 10:34:08 |
Message-ID: | 1153046049.2654.211.camel@localhost.localdomain |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sat, 2006-07-15 at 21:10 -0400, Greg Stark wrote:
> Hannu Krosing <hannu(at)skype(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Hannu Krosing | 2006-07-16 11:31:38 | Re: Forcing wal rotation |
Previous Message | Agent M | 2006-07-16 03:01:29 | Re: Online index builds |