> > prefetch_... is a much better name since its an existing industry term.
> > I'm not in favour of introducing the concept of spindles, since I can
> > almost hear the questions about ramdisks and memory-based storage.
>
> It's possible to make a case for exposing the internal number that's
> getting varied here, naming the parameter something like prefetch_depth,
> and letting people set that to whatever they want. Based on the current
> data I might suggest a default of 256, using 0 to turn the feature off
> altogether, and a maximum of at least 8192 and possibly more.
>
> In practice I expect there to only be a couple of popular values and the
> idea of fine-tuning is a bit questionable. I think that's what Greg Stark
> was driving at with how the value was re-spun. Instead of using
> effective_spindle_count, you could just as easily make a case for an enum
> like [off,low,medium,high] mapping to [0,16,256,8192]. From what I've
> seen so far, that would reduce tweaking time in the field considerably
> while not really changing the range of available behavior very much.
Tuning Postgres I/O already involves quite a few parameters called
buffersize, segment width, stripe size, etc.. I've never heard anything
from a disk manufacturer say this is wrong and we should just have
"spindle equivalents". I don't think we should dress this up too much,
that's all. We aren't going to make anybody's life any easier. But we
will probably generate lots of annoying phone calls to disk
manufacturers asking "so how many spindles is your subsystem worth in
Postgres terms?" to which they will shrug and say "no idea".
Is the behaviour of this sufficiently linear to be able to say that 3
spindles = 3 effective_spindles and 6=6 etc.? I would guess it won't be
and you're left with a name more misleading than useful.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
No comments:
Post a Comment