Re: [ADMIN] Query is stuck

From: <tv(at)fuzzy(dot)cz>
To: "Satish Burnwal (sburnwal)" <sburnwal(at)cisco(dot)com>
Cc: Bill Moran <wmoran(at)potentialtech(dot)com>, <pgsql-general(at)postgresql(dot)org>
Subject: Re: [ADMIN] Query is stuck
Date: 2010-04-13 14:25:59
Message-ID: 6013c776bd38b7738ff9e43815ce8adc@mail.gransy.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin pgsql-general


> INFO: "repcopy": scanned 3000 of 4652 pages, containing 128964 live rows
> and 0 dead rows; 3000 rows in sample, 199980 estimated total rows
> VACUUM
> controlsmartdb=# select distinct report_status from repcopy ;

According to the vacuum output, there are about 200000 rows in the
"repcopy" table, occupying roughly 40MB. And according to the explain plan
you've posted earlier, there's a seq scan for each row - that gives 200000
sequential scans on the table ... which is about 8TB of data. Sure, most of
the data will be read from disk cache / shared buffers etc. but still it's
a lot of data to process - that's why it takes so long.

I'd recommend creating a index on (dm_user, dm_ip) columns, but it depends
on how many different values are in these columns (the more the better).

What information do we need to give better recommendations:

1) info about structure of the "repcopy" table (column data types, indexes)
2) info about data (how many different values are there)
3) what does the system do when running the query (use 'top' or 'dstat' to
get iowait / CPU / disk / memory etc.)

regards
Tomas

In response to

Responses

Browse pgsql-admin by date

  From Date Subject
Next Message Jeffrey Gaynor 2010-04-13 17:04:43 SSL question
Previous Message Kevin Grittner 2010-04-13 13:54:50 Re: Getting the initdb parameter values

Browse pgsql-general by date

  From Date Subject
Next Message Brent Friedman 2010-04-13 14:26:04 General question about speed of functions
Previous Message Satish Burnwal (sburnwal) 2010-04-13 13:51:19 Re: [ADMIN] Query is stuck