On Wed, Jul 6, 2011 at 9:04 PM, Tomas Vondra t...@fuzzy.cz wrote:
Dne 6.7.2011 15:30, bakkiya napsal(a):
Any help, please?
According to the EXPLAIN ANALYZE output (please, don't post it to the
mailing list directly - use something like explain.depesz.com, I've done
that for you this time:
Thanks all for your help. It is really useful, I will modify the query and
post the result.
--
View this message in context:
http://postgresql.1045698.n5.nabble.com/100-CPU-Utilization-when-we-run-queries-tp4465765p4560941.html
Sent from the PostgreSQL - performance mailing list archive at
Any help, please?
--
View this message in context:
http://postgresql.1045698.n5.nabble.com/100-CPU-Utilization-when-we-run-queries-tp4465765p4556775.html
Sent from the PostgreSQL - performance mailing list archive at Nabble.com.
--
Sent via pgsql-performance mailing list
Dne 6.7.2011 15:30, bakkiya napsal(a):
Any help, please?
According to the EXPLAIN ANALYZE output (please, don't post it to the
mailing list directly - use something like explain.depesz.com, I've done
that for you this time: http://explain.depesz.com/s/HMN), you're doing a
UNIQUE over a lot of
On Wed, Jul 6, 2011 at 1:04 PM, Tomas Vondra t...@fuzzy.cz wrote:
Dne 6.7.2011 15:30, bakkiya napsal(a):
Any help, please?
According to the EXPLAIN ANALYZE output (please, don't post it to the
mailing list directly - use something like explain.depesz.com, I've done
that for you this time:
On 7/07/2011 3:04 AM, Tomas Vondra wrote:
That is done by sorting the data, and sorting is very CPU intensive task
usually. So the fact that the CPU is 100% utilized is kind of expected
in this case. So that's a feature, not a bug.
In general each process is hitting some bottleneck. It might be
Hi,
Sorry. I am posting the query details below.
Query:
SELECT DISTINCT events_rpt_v3.init_service_comp FROM public.events_rpt_v3
events_rpt_v3;
events_rpt_v3 is a view based on partition tables.
Number of rows in events_rpt_v3: 57878
vmstat o/p:
procs ---memory-- ---swap--
http://postgresql.1045698.n5.nabble.com/file/n4475458/untitled.bmp
--
View this message in context:
http://postgresql.1045698.n5.nabble.com/100-CPU-Utilization-when-we-run-queries-tp4465765p4475458.html
Sent from the PostgreSQL - performance mailing list archive at Nabble.com.
--
Sent via
On Wed, Jun 8, 2011 at 07:19, bakkiya bakk...@gmail.com wrote:
We have a postgresql 8.3.8 DB which consumes 100% of the CPU whenever we run
any query. We got vmstat output Machine details are below:
Any query? Does even SELECT 1 not work? Or SELECT * FROM sometable LIMIT 1
Or are you having
On 06/10/2011 03:39 PM, bakkiya wrote:
http://postgresql.1045698.n5.nabble.com/file/n4475458/untitled.bmp
404 file not found.
That's ... not overly useful.
Again, *PLEASE* read
http://wiki.postgresql.org/wiki/Guide_to_reporting_problems
and try posting again with enough information that
On 8/06/2011 12:19 PM, bakkiya wrote:
We have a postgresql 8.3.8 DB which consumes 100% of the CPU whenever we run
any query.
Yep, that's what it's supposed to do if it's not I/O limited. What's the
problem? Is the query taking longer than you think it should to execute?
Do you expect it to
11 matches
Mail list logo