Re: query performance, though it was timestamps,maybe just table size? - Mailing list pgsql-general

From Jeff Janes
Subject Re: query performance, though it was timestamps,maybe just table size?
Date
Msg-id CAMkU=1y3i6x5LDUBgV_MbRiBOxPdaebpqAsiU8qnV06f-WUSpA@mail.gmail.com
Whole thread Raw
In response to query performance, though it was timestamps,maybe just table size?  (Henry Drexler <alonup8tb@gmail.com>)
Responses Re: query performance, though it was timestamps,maybe just table size?  (Henry Drexler <alonup8tb@gmail.com>)
List pgsql-general
On Fri, Nov 30, 2012 at 5:22 AM, Henry Drexler <alonup8tb@gmail.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


pgsql-general by date:

Previous
From: hartrc
Date:
Subject: pg_basebackup questions
Next
From: Igor Neyman
Date:
Subject: Re: pg_listening_channels()