Re: Top -N Query performance issue and high CPU usage

From: yudhi s <learnerdatabase99(at)gmail(dot)com>
To: Rob Sargent <robjsargent(at)gmail(dot)com>, pgsql-general <pgsql-general(at)lists(dot)postgresql(dot)org>
Subject: Re: Top -N Query performance issue and high CPU usage
Date: 2026-02-02 06:33:08
Message-ID: CAEzWdqfZ6mbtjM1GPBp1LthS=MGUYng3Pw6hj+g6+054BA4VqA@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Mon, 2 Feb, 2026, 11:21 am Rob Sargent, <robjsargent(at)gmail(dot)com> wrote:

>
> > Thank you so much. I need to get back on the exact number of such
> queries which can hit the database. However, as 1000 of users will be
> there, so the possibility of all logging into the system on the same page
> at same time needs to be found out. Will double check on this.
> >
> > However, when you said caching :- The results on the base tables are
> going to be ~30-50 million. This landing page has filters on it so it may
> be of 30+ different
>
> I know I read OP’s earlier descriptions to suggest that each login saw the
> same data. I was wrong and I suspect the suggestion to cache goes out the
> window.
>
> The need for more resources now comes centre stage, right beside query
> tuning. You won’t get much help here on the latter problem without more DDL
> on the tables involved. Help on the hardware is just money - though most
> desktops these days are more powerful than that vert described up-thread

Won't , the materialized view having a minimum Delta refresh frequency(5-10
> minutes?) help in such scenarios? As the overhead of the query complexity
> will lie within the materialized view and it can be indexed as per the
> dynamic incoming filter conditions.

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Thiemo Kellner 2026-02-02 07:45:31 Re: Top -N Query performance issue and high CPU usage
Previous Message yudhi s 2026-02-02 04:17:06 Re: Top -N Query performance issue and high CPU usage