> js 之所以是单线程，主要为了避免资源竞争问题。

js 是单线程+无栈异步（ promise ）+回调异步（传统的 callback hell 就像 IndexedDB ）

> 但实际上 js 不可能是单线程，就比如 xhr 图片加载，xhr 在下载时没有阻塞主线程，那图片的下载必定不是在主线程执行，那必定有一个线程帮你执行下载工作，就是网络线程。

负责下载图片等网络请求的是 chrome 的 network thread ，其跟 js 无关

> 所以我认为 js 单线程是指你在 js 代码中无法像其它语言那样使用多线程模块创建一个线程执行一个代码块。

您可以用 worker 创建新的 js thread

> 只能使用预留的 API 调用现有的线程，如浏览器的 xhr Web Api ，node 的 fs 模块

因此 xhr/fetch 本质上是浏览器暴露的一套 api ，其标准化于 https://xhr.spec.whatwg.org https://fetch.spec.whatwg.org 他们存在的目的是允许您在 js thread 中与 network thread 通信，以派发您的下载图片的任务

> 那像 xhr 中在网络线程中要渲染图片，涉及到操作 dom ，就会出现资源竞争问题，所以必须放到任务队列中让主线程来进行

xhr/fetch 没有渲染图片，他们只负责网络请求相关的 payload （实际上跟 os socket 打交道处理网络栈已经够复杂了）
xhr/fetch 最终会给您一坨 byte[]也就是您的 http request 的 http response body ，以及相关的 response 元数据如 http header （ fetch 标准是都放在 https://developer.mozilla.org/en-US/docs/Web/API/Response 里）
要么您的 js thread 去取回这些 byte[]（例如通过 https://developer.mozilla.org/en-US/docs/Web/API/Response/arrayBuffer ）
要么是其他浏览器 thread 消费，比如有一个`<img src="url">`，那么 network thread 下载完了`url`后就会把 byte[]传给负责图片渲染和 css layout 的 thread ，让他们绘制这个<img>，这里同样没有 js 的事（即便您禁用了浏览器 js 也不会妨碍<img src>正常工作）
要么是没有任何人消费这些 byte[]，那就直接丢弃

#3 @sinnosong1 猜猜 Select-Object 是什么语义

试试 gpart https://www.freebsd.org/cgi/man.cgi?gpart(8)
或 gparted （如果您有 x11 ） https://gparted.org/display-doc.php%3Fname%3Dmoving-space-between-partitions

> 1GB 大小文件

这是 pgsql 的一个文件分片机制： https://www.postgresql.org/docs/current/storage-file-layout.html
> When a table or index exceeds 1 GB, it is divided into gigabyte-sized segments. The first segment's file name is the same as the filenode; subsequent segments are named filenode.1, filenode.2, etc. This arrangement avoids problems on platforms that have file size limitations. (Actually, 1 GB is just the default segment size. The segment size can be adjusted using the configuration option --with-segsize when building PostgreSQL.) In principle, free space map and visibility map forks could require multiple segments as well, though this is unlikely to happen in practice.

根据
https://dba.stackexchange.com/questions/48273/whats-stored-in-data-dir-base-of-postgresql
https://dba.stackexchange.com/questions/228114/why-is-my-postgres-base-directory-filling-up-rapidly
您有执行过[VACUUM]( https://www.postgresql.org/docs/current/routine-vacuuming.html#VACUUM-FOR-SPACE-RECOVERY)吗

#2 @codehz 并不需要`INSERT INTO ... ON DUPLICATE KEY UPDATE`（ PGSQL 又称`UPSERT`）因为这是仅插入而没有更新或删除（即 CRUD 只有 C ）
也可以直接`INSERT IGNORE`： https://dev.mysql.com/doc/refman/8.0/en/insert.html
> If you use the IGNORE modifier, ignorable errors that occur while executing the INSERT statement are ignored. For example, without IGNORE, a row that duplicates an existing UNIQUE index or PRIMARY KEY value in the table causes a duplicate-key error and the statement is aborted. With IGNORE, the row is discarded and no error occurs. Ignored errors generate warnings instead.

然后在每次`INSERT`后[`SELECT ROW_COUNT`]( https://dev.mysql.com/doc/refman/8.0/en/information-functions.html#function_row-count)就可以知道少了多少行没有被插入（由于 DUPLICATE 或其他错误）（但只有行的数量，而非精确的对应关系，如果需要知道具体少插入了哪些行仍然需要`SELECT`之前插入的行范围）

但不论 UPSERT 还是 IGNORE 都是从数据库层面缓解问题，他不是保证永不发生 DUPLICATE 错误，而是保证发生 DUPLICATE 错误后您的程序也能跑（因为一个改成了 UPDATE ，一个将 ERR 降级到 WARN ）

而我更需要避免的是这种类似 DUPLICATE 造成了数据冗余，但又完全符合数据库层的 UNIQUE 约束的问题：
https://i.imgur.com/l32gdQA.png
可以看到两个线程都插入了“完全一致”的行，除了 time 字段值分别是 1674453494 和 1674453492 （因此两者 INSERT 时都不会触发 DUPLICATE 错误）
而这是因为右侧线程在左侧线程于`12:39:54.874436`时间`COMMIT`之前就已经`SELECT`了，所以右侧不知道左侧即将`INSERT` time 为 1674453492 的“重复”行

对此问题我当然可以选择写一个基于[window function]( https://learnsql.com/blog/sql-window-functions-cheat-sheet/)的`DELECT`的后台 crontab （或是线程每次`INSERT`后都尝试`DELETE`一次）来定期执行删除这类冗余的“重复”行
但这跟`UPSERT/INSERT IGNORE`类似仍然是缓解问题而不是解决问题
而且`DELETE`作为事（`INSERT`）后补救也不可能解决更罕见（线程在同一秒内完成所有任务）的两个线程插入的所有字段都相同（也就是触发 DUPLICATE 错误）的场景