On Thu, 2020-10-15 at 01:21 -0400, Roger Hunwicks wrote:
> We have a large Django application running against a Postgresql database.
>
> When we run the test suite using Postgresql 10.7 in a Docker container
> we consistently get:
>
> Ran 1166 tests in 1291.855s
>
> When we first started running
We have a large Django application running against a Postgresql database.
The test suite for the application runs in GitLab-CI using Docker
Compose to run the unit tests inside the application container against
a Postgresql database running in another container.
When Django runs the unit tests fo
Based on the execution plan, it looks like the part that takes 13 seconds
of the total 14.4 seconds is just calculating the max time used in the
where clause. Anytime I see an OR involved in a plan gone off the rails, I
always always check if re-writing the query some other way may be faster.
How's
Is there no index on thread.spool? What about notification.user? How about
message.time (without thread as a leading column). Those would all seem
very significant. Your row counts are very low to have a query perform so
badly. Work_mem could probably be increased above 4MB, but it isn't hurting
th
Hi all,
We've been struggling with a slow query! -- and it's been exploding as rows
have been added to relevant tables. It seems like a fairly common workflow,
so we think we're overlooking the potential for an index or rewriting the
query.
I've linked a document compiling the information as per
