On 06/02/2016 01:42 PM, David G. Johnston wrote:
> Are you referring to right now or if we move the goal posts to making
> > this a per-statement reservation?
>
> I was assuming that we would have *both* per-operation and per-statement
> limits. I can see reasons for having both, I can see why power users
> would want both, but it's going to be overwhelming to casual users.
>
>
> Got that. The only problem on that front with the current setup is
> that right now we are saying: "at most use 3 of the 8 available
> processes": i.e., we tie ourselves to a fixed number when I think a
> better algorithm would be: "on/off/auto - default auto" and we detect at
> runtime whatever values we feel are most appropriate based upon the
> machine we are running on. If the user doesn't like our choices they
> can specify their own values. But the only specified values in the
> configurations would be those placed there automatically by the user.
> If value isn't specified but is required it gets set at startup and can
> be seen in pg_settings.
>
Well, the hard part here is that the appropriate value is based on the
level of concurrency in the database as a whole. For example, if it's a
website database with 200 active connections on a 32-core machine
already, you want zero parallelism. Whereas if it's the only current
statement on a 16-core VM, you want like 8.
That sounds like a heuristic, except that the number of concurrent
statements can change in milleseconds. So we'd really want to base this
on some sort of moving average, set conservatively. This will be some
interesting code, and will probably need to be revised several times
before we get it right. Particularly since this would involve scanning
some of the global catalogs we've been trying to move activity off of.
--
--
Josh Berkus
Red Hat OSAS
(any opinions are my own)