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

Поиск
Список
Период
Сортировка
От Jeff Janes
Тема Re: query performance, though it was timestamps,maybe just table size?
Дата
Msg-id CAMkU=1y3i6x5LDUBgV_MbRiBOxPdaebpqAsiU8qnV06f-WUSpA@mail.gmail.com
обсуждение исходный текст
Ответ на query performance, though it was timestamps,maybe just table size?  (Henry Drexler <alonup8tb@gmail.com>)
Ответы Re: query performance, though it was timestamps,maybe just table size?  (Henry Drexler <alonup8tb@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: hartrc
Дата:
Сообщение: pg_basebackup questions
Следующее
От: Igor Neyman
Дата:
Сообщение: Re: pg_listening_channels()