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?
|
Список | 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 по дате отправления: