- trim off all trailing delimiters: },"

- then add on a fixed suffix: "]}

- then try parsing as a standard json. Ignore results if fails to parse.

This works since the schema I’m parsing had a fairly simple structure where everything of interest was at a specific depth in the hierarchy and values were all strings.

But in general we aren’t trying to parse arbitrary documents, we are trying to parse a document with a somewhat-known schema. In this sense, we can parse them so long as the input matches the schema we implicitly assumed.

To me though the idea that to read like a single 16MB chunk you need to actually read like 4MB of data from 5 different hard drives and that this is faster is baffling.

It does seem like the former could be solved by just loosening up the grammar to allow you to specify things in any order. Eg this seems perfectly unambiguous:

  from customer
  group by c_custkey
  select c_custkey, count(*) as count_of_customers

“I'm planning on migrating the build system on Wednesday (26th); please let me know if you have any concerns.”

The original wording makes it sound like it's already been settled, so nobody will bother responding. But by saying planning, you might get some feedback.

I hate when people suggest that there is something insecure about using the password reset feature. Whether I chose to use it to get into my account without a password has no impact on the security of the account. The mere presence of this feature is what’s determining the security of my account.

Similarly, some services I use prompt me to verify via SMS or Email after I input the password, but oddly imply that using SMS is more secure than email. Makes no sense to me since either way the OTP should only be usable on this one session, and even if one is a less secure channel, it’s the presence of the weaker option in the first place that’s the problem, not the choice made by the user.