Re: oracle to psql migration - slow query in postgres

From: Jon Nelson <jnelson+pgsql(at)jamponi(dot)net>
To:
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: oracle to psql migration - slow query in postgres
Date: 2010-10-14 20:10:01
Message-ID: AANLkTinkZXnh+4+wnfzOHpHD87pAjqbwTFY8xUANoZg2@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin pgsql-performance

Just my take on this.

The first thing I'd do is think real hard about whether you really
really want 'numeric' instead of boolean, smallint, or integer. The
second thing is that none of your indices (which specify a whole bunch
of fields, by the way) have only just emailok, emailbounced, or only
the pair of them. Without knowing the needs of your app, I would
reconsider your index choices and go with fewer columns per index.

For this particular query I would think either two indexes (depending
on the cardinality of the data, one for each of emailok, emailbounced)
or one index (containing both emailok, emailbounced) would make quite
a bit of difference. Consider creating the indexes using a WITH
clause, for example:

CREATE INDEX members_just_an_example_idx ON members (emailok,
emailbounced) WHERE emailok = 1 AND emailbounced = 0;

Obviously that index is only useful in situations where both fields
are specified with those values. Furthermore, if the result is such
that a very high percentage of the table has those conditions a
sequential scan is going to be cheaper, anyway.

--
Jon

In response to

Responses

Browse pgsql-admin by date

  From Date Subject
Next Message bricklen 2010-10-14 20:23:12 Re: oracle to psql migration - slow query in postgres
Previous Message Tony Capobianco 2010-10-14 19:43:04 oracle to psql migration - slow query in postgres

Browse pgsql-performance by date

  From Date Subject
Next Message bricklen 2010-10-14 20:23:12 Re: oracle to psql migration - slow query in postgres
Previous Message Jon Nelson 2010-10-14 20:00:32 odd postgresql performance (excessive lseek)