I am consolidating the various naming points from this thread into one email:
>From Horiguchi-san: > A bit different thing, but I felt a little uneasy about some uses of > "pgstat_io_ops". IOOp looks like a neighbouring word of IOPath. On the > other hand, actually iopath is used as an attribute of io_ops in many > places. Couldn't we be more consistent about the relationship between > the names? > > IOOp -> PgStat_IOOpType > IOPath -> PgStat_IOPath > PgStat_IOOpCOonters -> PgStat_IOCounters > PgStat_IOPathOps -> PgStat_IO > pgstat_count_io_op -> pgstat_count_io So, because of the way the data structures contain arrays of each other the naming was meant to specify all the information contained in the data structure: PgStat_IOOpCounters are all IOOp (I could see removing the word "counters" from the name for more consistency) PgStat_IOPathOps are all IOOp for all IOPath PgStat_BackendIOPathOps are all IOOp for all IOPath for all BackendType The downside of this naming is that, when choosing a local variable name for all of the IOOp for all IOPath for a single BackendType, "backend_io_path_ops" seems accurate but is actually confusing if the type name for all IOOp for all IOPath for all BackendType is PgStat_BackendIOPathOps. I would be open to changing PgStat_BackendIOPathOps to PgStat_IO, but I don't see how I could omit Path or Op from PgStat_IOPathOps without making its meaning unclear. I'm not sure about the idea of prefixing the IOOp and IOPath enums with Pg_Stat. I could see them being used outside of statistics (though they are defined in pgstat.h) and could see myself using them in, for example, calculations for the prefetcher. >From Andres: Quoting me (Melanie): > > Introduce "IOOp", an IO operation done by a backend, and "IOPath", the > > location or type of IO done by a backend. For example, the checkpointer > > may write a shared buffer out. This would be counted as an IOOp write on > > an IOPath IOPATH_SHARED by BackendType "checkpointer". > I'm still not 100% happy with IOPath - seems a bit too easy to confuse with > the file path. What about 'origin'? I can see the point about IOPATH. I'm not wild about origin mostly because of the number of O's given that IO Operation already has two O's. It gets kind of hard to read when using Pascal Case: IOOrigin and IOOp. Also, it doesn't totally make sense for alloc. I could be convinced, though. IOSOURCE doesn't have the O problem but does still not make sense for alloc. I also thought of IOSITE and IOVENUE. > Annoying question: pg_stat_io vs pg_statio? I'd not think of suggesting the > latter, except that we already have a bunch of views with that prefix. As far as pg_stat_io vs pg_statio, they are the only stats views which don't have an underscore between stat and the rest of the view name, so perhaps we should move away from statio to stat_io going forward anyway. I am imagining adding to them with other iostat type metrics once direct IO is introduced, so they may well be changing soon anyway. - Melanie
