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