As a matter of habit, I put all inner joins that may limit the result set
as the first joins, then the left joins that have where conditions on them.
I am not sure whether the optimizer sees that only those tables are needed
to determine which rows will be in the end result and automatically
priori
pá 22. 11. 2019 v 15:06 odesílatel Sterpu Victor napsal:
> The CPU is at about 7% when I run the query and 5% are occupied by
> postgresql.
> CPU is Xeon E3 1240 v6 3.7Gh - not very good, but postgres is not
> overloading it.
>
> Tests are done on windows 2016 server so the next step was to try
The CPU is at about 7% when I run the query and 5% are occupied by
postgresql.
CPU is Xeon E3 1240 v6 3.7Gh - not very good, but postgres is not
overloading it.
Tests are done on windows 2016 server so the next step was to try and
change the priority of all the postgresql procesess to realtim
I did some testing and the results are surprising.
I did 3 tests:
Test 1
Test 2
Test 3
Test conditions
SHOW geqo: "on"
SHOW geqo_threshold: "5"
SHOW geqo: "on"
SHOW geqo_threshold: "12"
SHOW geqo: "off"
Planning Time
43691.910 ms
5114.959 ms
7305.504 ms
Execution Time
4.002 ms
3.987 ms
5.034 ms
T
I'm sorry, I messed up between a lot of queries . there is no
difference after running "VACUUM ANALYZE".
I guess this was to be expected as the database was just restored from
backup.
-- Original Message --
From: "Fırat Güleç"
To: "Sterpu Victor"
Cc: pgsql-performance@lists.postgr
This is interesting because "VACUUM ANALYZE" solved the problem on
postgresql 12.1, the planning time was cut down from 5165.742 ms to 517
ms.
This is great but I didn't think to do this on postgresql 12.1 because I
did the same thing on the production server(postgresql 9.5) and the
problem was
