Alexander Kuzmenkov

I started tsbench for the latest commit 5c8c97c20cba33bb3368b43430279583ef84b221, let's see if this PR influences the planning speed.

We're working on multinode insert/copy performance so probably it will get better after a release or two (2.8 or 2.9). What I can suggest for now: * update to 2.7...

> For reviewing purposes, it would be good to understand what change introduced the regression. I updated the description.

https://grafana.ops.savannah-dev.timescale.com/d/NdmLnOk4z/compare-benchmark-runs?orgId=1&var-branch=main&var-branch=release&var-branch=pr&var-postgres=14&var-run1=379&var-run2=397&var-threshold=0.02 Looks like this does improve some queries, although not all of them.

This is on 2.6.1, right? I thought it should have these memory problems fixed... At the first glance, the work_mem of 10 GB might be a little too large if...

It worked, but: ``` [00:07:49] [3160] LOG: server process (PID 4980) was terminated by exception 0xC0000409 ``` 0xc0000409 means STATUS_STACK_BUFFER_OVERRUN. Not sure what's going on there...

Note for maintainers: The distributed tables do leak some memory into ExecutorState context, so it's going to grow until the query ends. See `fdw_exec_foreign_update_or_delete` -> `async_request_set_wait_any_result`, `async_request_send_prepared_stmt_with_params`. Arguably they could...

Thanks for the repro script, could easily reproduce this at my machine.

Discussing on slack https://iobeam.slack.com/archives/CEKV5LMK3/p1660566945689239

The tentative fix was added here https://github.com/timescale/timescaledb/pull/4671, but we still need to add proper tests for this.