Re: Performance problem with a table with 38928077 record

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Giovanni Mancuso <gmancuso(at)babel(dot)it>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: Performance problem with a table with 38928077 record
Date: 2011-10-27 19:13:11
Message-ID: CA+TgmoanXurA=ZFqkNtx-GA5MsPX7mSKw007uA_DO4RRQwoyGg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

What is a bit strange about this is that you can do this:

On Fri, Oct 7, 2011 at 6:04 AM, Giovanni Mancuso <gmancuso(at)babel(dot)it> wrote:

> select count(*) from dm_object_perm;
> count
> ----------
> 38928077
> (1 row)
>

But not this:

If i run "explain analyze select * from dm_object_perm;" it goes on for many
> hours.
>

If I had to guess, I'd bet that the second one is trying to spool the
resultset in memory someplace and that's driving the machine into swap. But
that's just a shot in the dark. You might want to use tools like top,
vmstat, iostat, free, etc. to see what the system is actually doing while
this is running. I'd start the query up, let it run for 10 minutes or so,
and then see whether the machine is CPU-bound or I/O-bound, and whether the
amount of swap in use is growing.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Shaun Thomas 2011-10-27 20:31:00 Re: Performance problem with a table with 38928077 record
Previous Message Robert Haas 2011-10-27 18:46:54 Re: Shortcutting too-large offsets?