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
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? |