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
>
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 |