On Sat, Mar 7, 2020 at 8:00 AM Andres Freund <andres@anarazel.de> wrote:
> On 2020-03-02 18:28:41 +1300, Thomas Munro wrote:
> > * leaves room for a different setting for sequential prefetching
>
> I think if we want to split those at some point, we ought to split it if
> we have a good reason, not before. It's not at all clear to me why you'd
> want a substantially different queue depth for both.
Alright, I retract that part. It's known that at least on some
systems you might want to suppress that (due to some kind of bad
interaction with kernel readahead heuristics). But that isn't really
an argument for having a different queue size, it's an argument for
having a separate on/off switch.
> > * "degree" conveys the idea without using loaded words like "queue"
> > that might imply we know something about the I/O subsystem or that
> > it's system-wide like kernel and device queues
>
> Why is that good? Queue depth is a pretty well established term. You can
> search for benchmarks of devices with it, you can correlate with OS
> config, etc.
Queue depth is the standard term for an I/O queue that is shared by
all users. What we're talking about here is undeniably also a queue
with a depth, but it's a limit on the amount of concurrent I/O that
*each operator in a query* will try to initiate (for example: each
bitmap heap scan in the query, in future perhaps btree scans and other
things), so I was thinking that we might want a different name.
The more I think about this the more I appreciate the current vague GUC name!