public inbox for [email protected]
help / color / mirror / Atom feedRe: Top -N Query performance issue and high CPU usage
2+ messages / 2 participants
[nested] [flat]
* Re: Top -N Query performance issue and high CPU usage
@ 2026-02-02 06:33 yudhi s <[email protected]>
2026-02-02 07:45 ` Re: Top -N Query performance issue and high CPU usage Thiemo Kellner <[email protected]>
0 siblings, 1 reply; 2+ messages in thread
From: yudhi s @ 2026-02-02 06:33 UTC (permalink / raw)
To: Rob Sargent <[email protected]>; pgsql-general <[email protected]>
On Mon, 2 Feb, 2026, 11:21 am Rob Sargent, <[email protected]> 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.
^ permalink raw reply [nested|flat] 2+ messages in thread
* Re: Top -N Query performance issue and high CPU usage
2026-02-02 06:33 Re: Top -N Query performance issue and high CPU usage yudhi s <[email protected]>
@ 2026-02-02 07:45 ` Thiemo Kellner <[email protected]>
0 siblings, 0 replies; 2+ messages in thread
From: Thiemo Kellner @ 2026-02-02 07:45 UTC (permalink / raw)
To: [email protected]
Hi
Would it do any good to restrict the transaction date for the limit to something like "current timestamp - 1 day/hour/month". How about partitioning?
My two dimes
Thiemo
^ permalink raw reply [nested|flat] 2+ messages in thread
end of thread, other threads:[~2026-02-02 07:45 UTC | newest]
Thread overview: 2+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2026-02-02 06:33 Re: Top -N Query performance issue and high CPU usage yudhi s <[email protected]>
2026-02-02 07:45 ` Thiemo Kellner <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox