Re: 57 minute SELECT - Mailing list pgsql-performance

From Samuel Stearns
Subject Re: 57 minute SELECT
Date
Msg-id CB03CD8D2C3F9347BAFEC8EA9DD89C9318D37FD2@ISP-OSB-DAG2.win2k.iinet.net.au
Whole thread Raw
In response to Re: 57 minute SELECT  (Claudio Freire <klaussfreire@gmail.com>)
Responses Re: 57 minute SELECT
List pgsql-performance
Thanks, Claudio.

I'll have a look at the clustering.

We have also noticed that the same query with a datetime range of 3 hours (rather than 4 months) runs in just 30
seconds:

AND datetime <= '2013-10-03 10:03:49'
AND datetime >= '2013-10-03 07:03:49'


-----Original Message-----
From: Claudio Freire [mailto:klaussfreire@gmail.com]
Sent: Thursday, 3 October 2013 1:44 PM
To: Samuel Stearns
Cc: David Johnston; pgsql-performance@postgresql.org
Subject: Re: [PERFORM] 57 minute SELECT

On Wed, Oct 2, 2013 at 10:47 PM, Samuel Stearns <sstearns@staff.iinet.net.au> wrote:
> Thanks, Claudio:
>
> http://explain.depesz.com/s/WJQx

If you have a test database, and if it doesn't hurt other queries of course, try clustering on the ip index.

I believe your problem is that the index isn't helping much, it's probably hurting you in fact. If you cluster over ip,
however,the scan will go almost sequentially, and there will be no wasted bytes in the pages fetched, which will be
muchfriendlier on your I/O subsystem. 

If I were in your shoes, I'd cluster each of the monthly tables as they become inactive.


pgsql-performance by date:

Previous
From: Claudio Freire
Date:
Subject: Re: 57 minute SELECT
Next
From: Ivan Voras
Date:
Subject: Re: 57 minute SELECT