Re: query performance, though it was timestamps,maybe just table size?

From: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
To: Henry Drexler <alonup8tb(at)gmail(dot)com>
Cc: pgsql-general <pgsql-general(at)postgresql(dot)org>
Subject: Re: query performance, though it was timestamps,maybe just table size?
Date: 2012-11-30 18:42:47
Message-ID: CAMkU=1y3i6x5LDUBgV_MbRiBOxPdaebpqAsiU8qnV06f-WUSpA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Fri, Nov 30, 2012 at 5:22 AM, Henry Drexler <alonup8tb(at)gmail(dot)com> wrote:
> Hello, and thank you in advance.
>
>
> Beyond the date vs timestamp troubleshooting I did, I am not sure what else
> to look for, I know the increase of rows will have some affect but I just
> don't think the query should go from 4 minutes to over 50.

If the doubling of the size causes it to exceed the cache, when before
it did not, that could easily explain it.

...
> and
> massive.dateof <@ '(2012-07-22 17:00:00,2012-07-29 17:00:00]'::tsrange;

I don't think the <@ can use the btree index, but if you wrote it as a
"BETWEEN" it could.

> With a query plan of:
> "Index Scan using customer_id_sourcee on massive_m (cost=0.00..113.98
> rows=1 width=28)"

Can you report the EXPLAIN (ANALYZE, BUFFERS) instead?

Cheers,

Jeff

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Igor Neyman 2012-11-30 19:33:17 Re: pg_listening_channels()
Previous Message hartrc 2012-11-30 18:28:45 pg_basebackup questions