Re: slow query to improve performace

From: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
To: Ayub Khan <ayub(dot)hp(at)gmail(dot)com>
Cc: "pgsql-performa(dot)" <pgsql-performance(at)postgresql(dot)org>
Subject: Re: slow query to improve performace
Date: 2022-02-28 03:18:30
Message-ID: CAMkU=1wUubr0coupaEBo6u8pyOHt+HLxH=qZ+fidJUp81f53jQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On Fri, Feb 25, 2022 at 3:18 PM Ayub Khan <ayub(dot)hp(at)gmail(dot)com> wrote:

> Hi,
>
> Could some some verify the attached query to verify the performance and
> suggest some steps to improve it, this query is created as a view. This
> view is used to get the aggregates of orders based on its current status
>

I don't see how it is possible for that query to yield that plan. For
example, what part of that query could have been transformed into this part
of the plan "order_status_code <> ALL ('{T,J,C,D}'::bpchar[])"?

Well, I suppose some of the tables used in that query could themselves be
views over the same tables? In that case, we might need to know the
definitions of those views. As well as knowing the version, and seeing the
EXPLAIN (ANALYZE, BUFFERS) for the query, run after track_io_timing is
turned on.

Cheers,

Jeff

>

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message ldh@laurent-hasson.com 2022-02-28 16:50:54 RE: An I/O error occurred while sending to the backend (PG 13.4)
Previous Message Jeff Janes 2022-02-27 17:20:42 Re: Never Ending query in PostgreSQL