Matthias van de Meent

You can try for the 'options object' option: ``` javascript function foo(opts, ...args) { if (args.length 0) // function was not used as a class decorator {cls} = opts; return...

> add a separate endpoint to the pageserver that copies the initdb.tar.zst to a different location in S3, say same prefix but initdb-recovery.tar.zst I'd use a separate prefix instead, as...

One issue with our scale-to-zero is that we drop some statistics used by the autovacuum deamon to determine if the table should be vacuumed (specifically, all stats in the [cumulative...

C.f. [an internal discussion](https://neondb.slack.com/archives/C04DGM6SMTM/p1703077676522789) about an issue where autovacuum didn't trigger which resulted in measurably different performance.

> Autovacuum is definitely configured to run slowly. But as far as I know there are no some artificial delays (i.e. sleeps...). It does have delays, see `vacuum_delay_point()` in `src/backend/commands/vacuum.c`,...

> We would likely want some methodology where we could fetch pages in parallel, but the overhead of that could be too much at the moment and requires more research....

> Investigate why l2_distance (not just vector_l2_squared_distance) is called for index scans Wouldn't that be due to the plan used, and limitations of the PostgreSQL executor? ``` > EXPLAIN (costs...

> 1. Marking tuples as deleted (since `scan->kill_prior_tuple` is the only way to get this information). The built-in `btree` AM does some optimistic cleanup for non-hot updates where the indexed...

At various places: > "chain replication" The PostgreSQL term for this is "cascading replication" IIRC.

Why do we need this? Neither `VACUUM`, `TRUNCATE`, `DROP TABLE`, nor `DELETE` should increase the size of the data of a cluster (the resulting database should be as large or...