Re: Changing ORDER BY column slows query dramatically

Поиск
Список
Период
Сортировка
От Shaun Thomas
Тема Re: Changing ORDER BY column slows query dramatically
Дата
Msg-id 51686787.3050308@optionshouse.com
обсуждение исходный текст
Ответ на Changing ORDER BY column slows query dramatically  (brick pglists <brickpglists@gmail.com>)
Ответы Re: Changing ORDER BY column slows query dramatically  (brick pglists <brickpglists@gmail.com>)
Список pgsql-performance
On 04/12/2013 11:51 AM, brick pglists wrote:

>           ->  Index Scan Backward using event_20130405_id_pk on
> event_20130405 e  (cost=0.00..612732.34 rows=1889715 width=34) (actual
> time=2076.812..2111.274 rows=10100 loops=1)
 >                 Filter: ((tstamp_utc >= '2013-04-05
 > 10:00:00'::timestamp without time zone) AND (tstamp_utc <= '2013-04-05
 > 18:00:00'::timestamp without time zone) AND (date_utc =
 > '2013-04-05'::date) AND (org_id = 216471))

This right here is your culprit. The planner thinks it'll be faster to
grab 100 rows by scanning your primary key backwards and filtering out
the matching utc timestamps and other criteria.

Since it doesn't show up in your GUC list, you should probably increase
your default_statistics_target to 400 or more, analyze, and try again.
The heuristics for the dates aren't complete enough, so it thinks there
are few matches. If that doesn't work and you want a quick, but ugly fix
for this, you can create the following index:

CREATE INDEX event_20130406_id_desc_tstamp_utc_idx
     ON event_20130406 (id DESC, tstamp_utc);

--
Shaun Thomas
OptionsHouse | 141 W. Jackson Blvd. | Suite 500 | Chicago IL, 60604
312-676-8870
sthomas@optionshouse.com

______________________________________________

See http://www.peak6.com/email_disclaimer/ for terms and conditions related to this email


В списке pgsql-performance по дате отправления:

Предыдущее
От: Rodrigo Barboza
Дата:
Сообщение: Re: Segment best size
Следующее
От: brick pglists
Дата:
Сообщение: Re: Changing ORDER BY column slows query dramatically