Re: oracle to psql migration - slow query in postgres

Поиск
Список
Период
Сортировка
Искать
От
Ivan Voras
Тема
Re: oracle to psql migration - slow query in postgres
Дата
Msg-id
i97pca$f1h$1@dough.gmane.org
Ответ на
Список
Дерево обсуждения
oracle to psql migration - slow query in postgres Tony Capobianco <tcapobianco@prospectiv.com>
Re: oracle to psql migration - slow query in postgres Merlin Moncure <mmoncure@gmail.com>
Re: oracle to psql migration - slow query in postgres Cédric Villemain <cedric.villemain.debian@gmail.com>
Re: oracle to psql migration - slow query in postgres Maciek Sakrejda <msakrejda@truviso.com>
Re: oracle to psql migration - slow query in postgres Jon Nelson <jnelson+pgsql@jamponi.net>
Re: oracle to psql migration - slow query in postgres Mladen Gogala <mladen.gogala@vmsinfo.com>
Re: oracle to psql migration - slow query in postgres Tony Capobianco <tcapobianco@prospectiv.com>
Re: oracle to psql migration - slow query in postgres Samuel Gendler <sgendler@ideasculptor.com>
Re: oracle to psql migration - slow query in postgres Mladen Gogala <mladen.gogala@vmsinfo.com>
Re: oracle to psql migration - slow query in postgres bricklen <bricklen@gmail.com>
Re: oracle to psql migration - slow query in postgres "Igor Neyman" <ineyman@perceptron.com>
Re: oracle to psql migration - slow query in postgres Tony Capobianco <tcapobianco@prospectiv.com>
Re: oracle to psql migration - slow query in postgres "Igor Neyman" <ineyman@perceptron.com>
Re: oracle to psql migration - slow query in postgres Tony Capobianco <tcapobianco@prospectiv.com>
Re: oracle to psql migration - slow query in postgres Ivan Voras <ivoras@freebsd.org>
Re: oracle to psql migration - slow query in postgres "Pierre C" <lists@peufeu.com>
On 10/14/10 21:43, Tony Capobianco wrote:


> We have 4 quad-core processors and 32GB of RAM.  The below query uses
> the members_sorted_idx_001 index in oracle, but in postgres, the
> optimizer chooses a sequential scan.
>
> explain analyze create table tmp_srcmem_emws1
> as
> select emailaddress, websiteid
>    from members
>   where emailok = 1
>     and emailbounced = 0;
>                                                            QUERY
> PLAN
> ------------------------------------------------------------------------------------------------------------------------------
>   Seq Scan on members  (cost=0.00..14137154.64 rows=238177981 width=29)
> (actual time=0.052..685834.785 rows=236660930 loops=1)
>     Filter: ((emailok = 1::numeric) AND (emailbounced = 0::numeric))
>   Total runtime: 850306.220 ms
> (3 rows)

> Indexes:
>      "email_website_unq" UNIQUE, btree (emailaddress, websiteid),
> tablespace "members_idx"
>      "member_addeddateid_idx" btree (addeddate_id), tablespace
> "members_idx"
>      "member_changedateid_idx" btree (changedate_id), tablespace
> "members_idx"
>      "members_fdate_idx" btree (to_char_year_month(addeddate)),
> tablespace "esave_idx"
>      "members_memberid_idx" btree (memberid), tablespace "members_idx"
>      "members_mid_emailok_idx" btree (memberid, emailaddress, zipcode,
> firstname, emailok), tablespace "members_idx"
>      "members_sorted_idx_001" btree (websiteid, emailok, emailbounced,
> addeddate, memberid, zipcode, statecode, emailaddress), tablespace
> "members_idx"
>      "members_src_idx" btree (websiteid, emailbounced, sourceid),
> tablespace "members_idx"
>      "members_wid_idx" btree (websiteid), tablespace "members_idx"

PostgreSQL doesn't fetch data directly from indexes, so there is no way 
for it to reasonably use an index declared like:

"members_sorted_idx_001" btree (websiteid, emailok, emailbounced, 
addeddate, memberid, zipcode, statecode, emailaddress)

You need a direct index on the fields you are using in your query, i.e. 
an index on (emailok, emailbounced).

OTOH, those columns look boolean-like. It depends on what your data set 
is, but if the majority of records contain (emailok=1 and 
emailbounced=0) an index may not help you much.
В списке pgsql-performance по дате отправления
От: bricklen
Дата:
От: Cédric Villemain
Дата:
FAQ