I would look at optimizing the query to increase performance. SELECT *
has room for improvement.
Also check out the book Mastering PostgreSQL 11 (or whatever version).
There are some good tips in there like using EXPLAIN to analyze the
query plan.
Looking at/setting max_parallel_workers_per_gat
The logs were helpful. You may want to see the statements around the
errors, as more detail may be there such as the SQL statement associated
with the error.
Deadlocks are an indicator that the client code needs to be examined for
improvement. See
https://www.cybertec-postgresql.com/en/postgres
Hey,
> That wait event according to documentation is "Waiting to access the
> multixact member SLRU cache." SLRU = segmented least recently used
> cache
I see, thanks!
> if you are low on memory, it can slow down the allocation of
> buffers. Do you have a query that is a "select for update" run
If you get a chance, showing the `top` output might be useful as well. For
instance if you are low on memory, it can slow down the allocation of
buffers. Another thing to look at is `iostat -x -y` and look at disk util
%. This is an indicator, but not definitive, of how much disk access is
going
