On 2024-02-23 at 15:35, Stefan Monnier wrote: >>> but what are the advantages of journald's representation compared >>> to a naive one? >> >> in short: querability without text parsing. That's about it. > > They have to parse the binary format, so that's not in and of itself > an upside compared to parsing CSV. > > I've made my share of bad design decisions that don't pan out. But > there's always an upside to my decision (even when it turns out it > speeds up only those cases which can never occur, because of some > other aspect of the system). > > AFAICT the format is *not* just a plain sequence of log entries, so > there's some additional structure which is intended to speed up some > operations. > > IOW, even if contrived, there should be *some* use case where it > does better than CSV, no? I can think of two possibilities, just offhand, in no particular order: * No need to parse the timestamps, et cetera, and take the risk that someone put in one that's in a format you don't expect; the times are stored internally in a consistent guaranteed format, so you can just use internal reader functions (paired with, and updated alongside, the internal writer functions) and be done with it. * No need to worry about handling log entries that *contain* commas, or whatever other element was chosen as the separator. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw
Attachment:
signature.asc
Description: OpenPGP digital signature