From: | Richard Huxton <dev(at)archonet(dot)com> |
---|---|
To: | Tobias Brox <tobias(at)nordicbet(dot)com> |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: "nice"/low priority Query |
Date: | 2005-08-03 08:53:29 |
Message-ID: | 42F08609.5060709@archonet.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Tobias Brox wrote:
> [Tobias Brox - Tue at 06:04:34PM +0200]
>
>>(...) and at one
>>point in the code I'm even asking the database for "explain plan", grepping
>>out the estimated cost number, and referring the user to take contact with
>>the IT-dept if he really needs the report. But I digress.
>
>
> I just came to think about some more "dirty" tricks I can do. I have turned
> on stats collection in the configuration; now, if I do:
>
> select count(*) from pg_stat_activity where not current_query like '<IDLE>%';
>
> or, eventually:
>
> select count(*) from pg_stat_activity
> where not current_query like '<IDLE>%' and query_start+'1 second'<now();
>
> it will give a hint about how busy the database server is, thus I can
> eventually let the application sleep and retry if there are any other heavy
> queries in progress.
Or - create a table with an estimated_cost column, when you start a new
"heavy" query, insert that query's cost, then sleep
SUM(estimated_cost)/100 secs or something. When the query ends, delete
the cost-row.
Hmm - actually rather than dividing by 100, perhaps make it a tunable value.
--
Richard Huxton
Archonet Ltd
From | Date | Subject | |
---|---|---|---|
Next Message | Meetesh Karia | 2005-08-03 12:48:38 | Re: Planner incorrectly choosing seq scan over index scan |
Previous Message | Tobias Brox | 2005-08-02 19:59:15 | Re: "nice"/low priority Query |