Re: Help with tuning this query (more musings)

Поиск
Список
Период
Сортировка
От Richard Huxton
Тема Re: Help with tuning this query (more musings)
Дата
Msg-id 4226B787.3090605@archonet.com
обсуждение исходный текст
Ответ на Re: Help with tuning this query (more musings)  ("Ken Egervari" <ken@upfactor.com>)
Список pgsql-performance
Ken Egervari wrote:
>
> Hash IN Join  (cost=676.15..1943.11 rows=14 width=91) (actual
> time=250.000..328.000 rows=39 loops=1)
>  Hash Cond: ("outer".carrier_code_id = "inner".id)
>  ->  Merge Join  (cost=661.65..1926.51 rows=392 width=91) (actual
> time=250.000..328.000 rows=310 loops=1)
>        Merge Cond: ("outer".current_status_id = "inner".id)
>        ->  Index Scan using shipment_current_status_id_idx on shipment s
> (cost=0.00..2702.56 rows=27257 width=66) (actual time=0.000..110.000
> rows=27711 loops=1)
>              Filter: ((current_status_id IS NOT NULL) AND (is_purged =
> false))

There's a feature in PG called partial indexes - see CREATE INDEX
reference for details. Basically you can do something like:

CREATE INDEX foo_idx ON shipment (carrier_code_id)
WHERE current_status_id IS NOT NULL
AND is_purged = FALSE;

Something similar may be a win here, although the above index might not
be quite right - sorry, bit tired at moment.

--
   Richard Huxton
   Archonet Ltd

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

Предыдущее
От: "Ken Egervari"
Дата:
Сообщение: Re: Help with tuning this query (with explain analyze finally)
Следующее
От: "Ken Egervari"
Дата:
Сообщение: Re: Help with tuning this query (with explain analyze finally)