On Fri, 26 Jan 2024 at 17:23, Jean-Christophe Boggio
wrote:
> Let me know if I can do anything to provide you with more useful
> benchmark. The DB is still very small so it is easy to do tests.
What I was looking to find out was if there was some enable_* GUC that
you could turn off that would ma
Hello,
In case it might be useful, I made some more tests.
On my dev computer (a notebook) I installed:
PostgreSQL 15.5 (Ubuntu 15.5-1.pgdg23.10+1) on x86_64-pc-linux-gnu,
compiled by gcc (Ubuntu 13.2.0-4ubuntu3) 13.2.0, 64-bit
and
PostgreSQL 16.1 (Ubuntu 16.1-1.pgdg23.10+1) on x86_64-pc-li
David,
It would be good to narrow down which plan node is causing this. Can
you try disabling various planner enable_* GUCs before running EXPLAIN
(SUMMARY ON) with \timing on and see if you can find
which enable_* GUC causes the EXPLAIN to run more quickly? Just watch
out for variations in t
David Rowley writes:
> I do wonder now if it was a bad idea to make Memoize build the hash
> table on plan startup rather than delaying that until we fetch the
> first tuple. I see Hash Join only builds its table during executor
> run.
Ouch! If it really does that, yes it's a bad idea.
On Fri, 26 Jan 2024 at 02:31, Jean-Christophe Boggio
wrote:
> You are absolutely correct : the EXPLAIN without ANALYZE gives about the same
> results. Also, minimizing the amount of workmem in postgresql.conf changes
> drastically the timings. So that means memory allocation is eating up a lot
Hello David,
Thanks for your answer.
Le 23/01/2024 à 11:41, David Rowley a écrit :
If you're using psql, if you do \timing on, how long does EXPLAIN take
without ANALYZE? That also goes through executor startup and shutdown.
You are absolutely correct : the EXPLAIN without ANALYZE gives about
