What version by the way? Do you get a faster execution if you disable
sequential scan? Or set parallel workers per gather to 0? Your estimates
look decent as do cache hits, so other than caching data or upgrading
hardware, not sure what else there is to be done.
Although... you are hitting 70k blo
Hi,
Below query always shows up on top in the CPU matrix. Also despite having
indexes it does sequential scans(probably because WHERE condition satisfies
almost all of the data from table). This query runs on the default landing
page in application and needs to fetch records in less that 100 ms wit
Roger Hunwicks writes:
> ...
> However, even though we have similar performance for 12.4 for most
> test runs, it remains very variable.
> ...
> I think we have narrowed down the problem to a single, very complex,
> materialized view using CTEs; the unit tests create the test data and
> then refre
Hi all,
Thanks, Michael (and Martin other thread)! We added those indexes you
suggested, and went ahead and added indexes for all our foreign keys. We
also added one combination index on notification (user, time). It led to a
small constant factor speed up (2x) but is still taking a 13+ seconds. :
On 10/15/20 1:21 AM, Roger Hunwicks wrote:
>
> I think we have narrowed down the problem to a single, very complex,
> materialized view using CTEs; the unit tests create the test data and
> then refresh the materialized view before executing the actual test
> code.
>
Have you checked to see if
