Goran Schwarz

Any traction on the "Block Selection" feature? (it has been open for a **while**)

As an "inspiration"... here are some examples from other vendors! Oracle Explain output: https://blogs.oracle.com/optimizer/how-do-i-display-and-read-the-execution-plans-for-a-sql-statement Postgres Explain output: https://thoughtbot.com/blog/reading-an-explain-analyze-query-plan https://www.postgresql.org/docs/9.4/using-explain.html Sybase (or SQL Server version 4.2 and possibly 6.0 and 7.0):...

A easier alternative to "print" the plan as **plain text**, to include it into mail etc, would be to use "classic" html tables (which wont depends on JavaScript to draw...

You suggestion, **does** help: (no more long freeze)*, but on the other hand then some functionality get lost * `setMarkOccurrences(false)` * or `errorStrip.setShowMarkedOccurrences(false)` a better option than `setMarkOccurrences(false)` less functionality...

Thanks for the quick response! And I have no *low-hanging fruit for performance improvements*

I see that you get the "correct" row at row 3 (is that a JDBC Connection or "something else") What does the previous rows say? Below is my full output...

If it's a config issue... here are my config for version `PostgreSQL 16.2 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 11.4.1 20230605 (Red Hat 11.4.1-2), 64-bit` Note: all config is done...

I totally agree with you! There should be **no** difference if I execute `select query_id, pid, query, version() from pg_stat_activity where pid = pg_backend_pid()` from `psql` or from a `JDBC`...

I can verify that `preferQueryMode=simple` does change the behavior (`query_id` now has a value) Then: **why** isn't `simple` the *default* (**probably** for some other good reason: like *performance* or *something...

> To avoid SQL injection So a pretty good reason to **not** go to `preferQueryMode=simple` > Well .... we don't control everything :( But a bug/feature-request for the issue can...