Re: 57 minute SELECT

From: Claudio Freire <klaussfreire(at)gmail(dot)com>
To: Samuel Stearns <sstearns(at)staff(dot)iinet(dot)net(dot)au>
Cc: David Johnston <polobo(at)yahoo(dot)com>, "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org>
Subject: Re: 57 minute SELECT
Date: 2013-10-03 01:45:41
Message-ID: CAGTBQpbMrJCTTicpGwfRRaHQ5haitdeqA9hCSpBiTFALYZVoMg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On Wed, Oct 2, 2013 at 10:17 PM, Samuel Stearns
<sstearns(at)staff(dot)iinet(dot)net(dot)au> wrote:
> The last part, the EXPLAIN, is too big to send. Is there an alternative way
> I can get it too you, other than chopping it up and sending in multiple
> parts?

Try explain.depesz.com

On Wed, Oct 2, 2013 at 10:30 PM, Samuel Stearns
<sstearns(at)staff(dot)iinet(dot)net(dot)au> wrote:
>
> EXPLAIN:
>
> QUERY PLAN
> -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> Hash Join (cost=408.53..1962721.39 rows=98068 width=126) (actual time=30121.265..3419306.752 rows=1929714 loops=1)
> Hash Cond: (public.syslog_master.ip = public.devices.ip)

So your query is returning 2M rows.

I think you should try lowering work_mem. 512M seems oversized for a
query this complex on a system with 1G. You may be thrashing the OS
cache.

Also, you seem to have a problem with constraint exclusion. Some of
those bitmap heap scans aren't necessary, and the planner should know
it. Are you missing the corresponding CHECK constraints on datetime?

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Samuel Stearns 2013-10-03 01:47:29 Re: 57 minute SELECT
Previous Message Samuel Stearns 2013-10-03 01:35:25 Re: 57 minute SELECT